ISO 27001 Secure Development Policy: How to Write (& Template)

Time needed: 1 hour and 30 minutes

How to write an ISO 27001 Secure Development Policy

1. Create your version control and document mark-up

   ISO 27001 documents require version control of the author, the change, the date and the version as well as document mark up such as document classification.

2. Write the ISO 27001 Secure Development Policy contents page

   Document Version Control
   Document Contents Page
   Secure Development Policy
   Purpose
   Scope
   Principle
   Segregation of Environments
   Secure Development Coding Guidelines
   Development Code Repositories
   Development Code Reviews
   Development Code Approval
   Testing
   Test Data
   Promoting Code to Production

3. Write the ISO 27001 Secure Development Policy purpose

   The purpose of this policy is to ensure information security is designed and implemented within the development lifecycle.

4. Write the ISO 27001 Secure Development Policy principle

   System development of bespoke company software solutions.
   All employees and third-party users.

5. Write the ISO 27001 Secure Development Policy scope

   Secure software and system engineering principles and standards are implemented and tested.
   Information security and privacy are by design and default.

6. Describe the segregation of environments

   Development, test, and production environments are separated and do not share common components.
   Development, test, and production environments are on separate networks.
   There is a segregation of administrative duties between development and test, and production.

7. Explain the secure development coding guidelines

   Software is designed and developed based on industry secure coding guidelines for the coding technology and the Open Web Application Security Project (OWASP).
   The NCSC government guidelines for secure development are considered: https://www.ncsc.gov.uk/collection/developers-collection
   The NIST Whitepaper on MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF are considered:
   https://csrc.nist.gov/CSRC/media/Publications/white-paper/2019/06/07/mitigating-risk-of-software-vulnerabilities-with-ssdf/draft/documents/ssdf-for-mitigating-risk-of-software-vulns-draft.pdf

8. Define the use of development code repositories

   Development code is stored in a secure code repository that enforces and meets the requirements of the access control policy and segregation of duty.
   Development code repositories enforce version control and appropriate version archiving.

9. Explain the approach to development code reviews

   Code is reviewed prior to release by skilled personnel other than the code author / developer.
   Code is reviewed against the secure development coding guidelines.
   Code reviews employ manual and automated techniques.

10. Describe development code approval

    Code is approved before being promoted into test or production.

11. Define testing

    All pre-production testing occurs in a test environment.
    The test environment mirrors as far as possible the production environment.
    Application security testing is performed using manual and automated techniques.
    Testing is performed that as a minimum test for the OWASP top 10.
    External penetration testing is performed prior to initial release and then periodically or after a significant change.
    All public facing web applications are tested using manual or automated vulnerability security tools or methods at least annually or after a significant change.
    All vulnerabilities identified as part of the testing phase including penetration testing are corrected prior to promotion to production or managed via the risk management process.
    Test results including penetration testing are additionally reported to the Management Review Team.
    All penetration testing is conducted by an external specialist company.

12. Give guidelines on the use of test data

    Production data is never used for testing or development.
    Card holder data is never used for testing or development.
    Personal data is never used for testing or development.
    If sensitive information is required as part of the testing process it is:
    – sanitised,
    – anonymised or
    – pseudo anonymised.

13. Explain promoting code to production

    Code is promoted to production by approved personnel and is subject to the documented change control process.
    The production environment is backed up prior to the promotion of code to production to facilitate roll back for a failed change.
    Test data is removed before the application is promoted to production.
    No development files or test data are stored in the production environment.