Secure Development Policy


The protection of our development environment and the software services that we provide is crucial to meeting the requirements of our business, and of our customers. Ensuring that security is integral to our development process helps us to minimise the possibility of introducing vulnerabilities into our development systems and software, reducing the risk of data breaches or service unavailability. Management are committed to the security of our application services, and have developed and approved this secure development policy in line with the requirements of the ISO 27001 standard for information security, and our organisation’s business requirements. This document sets out the approved secure development policy so that it can be clearly communicated to all employees, contractors, and third-parties who have responsibilities for developing, managing, and maintaining our software and development environment.


This policy shall apply to the development and administration of all software applications that fall within the scope of our organisation’s ISMS.


All employees, contractors, and third-parties who have responsibility for the design, development, administration, and monitoring of our development environment and software applications shall adhere to this Secure Development Policy. These include, but are not limited to, the following roles:

  • Development team leads
  • Application architects
  • Application developers
  • Software engineers
  • Project managers
  • System administrators
  • Network engineers
  • Application development service providers
  • Cloud services providers
  • Cloud security architects
  • Information security analysts
  • System owners
  • System testers

For the purposes of this document, employees, contractors, and third-parties who carry out these roles shall be collectively referred to as “developers”.


This Secure Development Policy shall be communicated to all employees and agency staff as part of the relevant department training programme, and periodically following any changes to the policy. All contractors and third-parties providing development services or involved in development projects which interact with our services shall be provided with a copy of this policy as part of the process for contracting services. Contractors and third-parties shall be re-issued with updated versions of this policy periodically, and following any changes.

Disciplinary Process

Where a developer performs an activity or activities in breach of this Secure Development Policy, they shall be subject to the disciplinary process documented in the HR Manual, or the applicable service contract.


Management is committed to the continual improvement of our Secure Development Policy, and shall review this document on an annual basis, or whenever an independent review of our organisation’s ISMS reveals a non-conformance or opportunity for improvement. The Management Review shall determine if this policy continues to meet the requirements of our organisation.

Management also endeavours to plan our business operations so that our applications are not misused, either intentionally or unintentionally. This is done by identifying and assigning separate duties and responsibilities to guard against misuses such as fraud, or malicious insider activities, etc. Where a developer identifies potential conflicts or misuse due to improper planning and assignment of duties, developers should raise their concern immediately with their line manager, or the ISMS Manager.

1. Maintaining Security Awareness

Our organisation recognises the importance of maintaining robust security measures to protect our applications and services against potential vulnerabilities and threats. While malicious attackers constantly seek to exploit weaknesses in software and web-based systems, we are committed to implementing proactive measures to mitigate these risks.
To achieve this goal, developers are encouraged to stay informed about secure coding practices and emerging threats. While adherence to specific training programs such as the OWASP Top 10 standard is beneficial, we understand that different developers may have varying schedules and learning preferences.

Key Points:

  • Awareness and Education: Developers are encouraged to stay informed about secure coding best practices through a variety of sources, including relevant security alert feeds, blogs, forums, and industry publications.
  • Continuous Learning: Developers should regularly review security alerts and notifications to assess their potential impact on our development environment and applications.
  • Training and Development: In addition to completing the annual formal security awareness training exercise, developers are encouraged to explore supplementary learning opportunities such as self-study options, workshops, or online courses to further their skills in application security. Active engagement in professional development activities is essential for staying abreast of evolving security practices.
  • Documentation: While HR may retain records of certain training activities as part of the employee training program, developers are advised to maintain documentation of any external security training they pursue and submit the documentation to HR. This includes certificates of attendance or completion obtained from sources outside the organisation’s provided training. Keeping thorough records and sharing them with HR ensures transparency and completeness in documenting ongoing professional development efforts related to security training.
  • Collaboration: Developers should maintain open communication with relevant service and technology providers to stay informed about potential vulnerabilities or issues related to the applications and services they work with.
  • Data Handling and Retention: Developers should regularly review and adhere to our Policy: Data Handling & Retention Guidelines to ensure compliance with our requirements for the protection and retention of data.

2. Secure Development Approach

No matter which software development methodology is used, our organisation requires that information security considerations and secure coding practices are embedded into the software development lifecycle (SDLC). This section provides guidance for how security is considered at each stage of the SDLC. The policies documented should not be considered exhaustive, and developers may identify additional methods for implementing controls.

The below diagram illustrates how security considerations are typically included throughout the SDLC:

Evercam's Secure Development Policy

Security Considerations in SDLC Diagram

2.1 Defining Requirements

When determining the functionality of the proposed new service or service update, security considerations must be included as part of the business requirements. The following policies shall apply:

  • Developers shall ensure that the requirements for information security documented in our Information Systems Security Policy are adhered to.
  • Developers shall ensure that the data protection principles and retention requirements set out in our Data Handling & Retention Guidelines are adhered to.
  • Developers shall ensure that the data and assets impacted are identified, recorded to our Critical Asset Register where necessary, and assessed to determine their value and appropriate handling and access requirements.
  • Developers shall ensure that our Change Control Procedure has been followed for normal, major, and emergency changes. Following our requirements for change control shall ensure that appropriate risk and data protection assessments are conducted, along with identifying applicable legal and regulatory considerations.
  • Where changes are classified as standard changes, developers shall ensure suitable peer review and acceptance controls are built into the development workflow.
  • Developers should ensure that they consider the availability and capacity requirements of proposed new services or service updates.
  • Where necessary, developers should consider using security sprints as part of the development approach.

2.2 Security in Design

When developing the software service, feature, or application, developers shall ensure security requirements are included in the design stage. By leveraging secure engineering principles, developers will reduce the risk of our services and applications being compromised by malicious attackers. This section documents secure engineering principles that developers should include in the design stage of development. Developers should ensure that they are appropriately trained to understand and implement these principles. Secure engineering principles include, but are not be limited to:

Principle Description
Data validation Data validation may include input validation and output encoding. Whitelisting of characters and translation of characters to safe or approved forms provides protection against attacks such as XSS, XFS, SQL injection, buffer overflow, etc.
Data minimisation Data collected, processed, and/or generated by the service, feature, or application shall always be limited to what is absolutely necessary to accomplish the intended purpose. For example, where application logs are generated to identify events about capacity, it may be unnecessary to automatically include user names and their device information in the log data.
Authentication Appropriate authentication mechanisms shall always be used unless the resources or webpages are intended for public access. Requirements for password management are set out in our Information Systems Security Policy, and shall be implemented for all services and users.

Where users of a service, feature, or application will be required to configure their own authentication policies as part of a shared responsibility model, appropriate controls and tools shall be developed and provided so that authoritative users can securely control and manage user accounts.

Authorisation Authorisation controls shall be used to ensure only authorised services and users have access to application resources, accounts, data, and code. Authorisation should be re-validated periodically to ensure access privileges have not changed.


Where users of a service, feature, or application will be required to perform their own access management as part of a shared responsibility model, appropriate controls and tools shall be developed and provided so that users can set and monitor their required levels of access, and ensure access privileges are correct.

Secure by default Default settings for services, features, or applications shall always prioritise user or organisational security so that data is automatically protected. This means that users shall be required to take little or no action to ensure the security of their data, and any automatic sharing of data shall be limited to only what is necessary. For example, a user profile may contain personal contact details, education information, and leave status data. Where only the sharing of contact details is necessary for the proper operation of the application, developers shall not:

  • Make input fields mandatory for education and leave status information
  • Share any of that data by default

The user should have to opt-in, or enable, any additional sharing features, as required. Users should not have to opt-out of, or disable, the sharing of data.

Session management Session management controls help to prevent user impersonation and compromise of session IDs. Session management controls may include:

  • Setting of security flags and secure paths for cookies
  • Session and session ID expiry
  • Preventing session re-activation and implementing correct session logout behaviour
  • Setting correct HTTP referer controls to filter sensitive information
Fail secure Where control mechanisms such as authentication, access control, encryption, and system exceptions may fail, they should not fail in an insecure way. For example, where authentication fails due to an exception, the authentication request should be denied.
Cryptographic techniques Encryption and cryptographic keys used to protect data shall meet the requirements for cryptographic control as documented in our Information Systems Security Policy, or where not specifically documented in our policy, they shall comply with the FIPS 140-2 or equivalent standard (


Where users of a service, feature, or application will be required to implement their own cryptographic controls as part of a shared responsibility model, legal, or regulatory requirement, appropriate controls and tools for managing encryption shall be developed and provided to users, where possible. This may include the ability to apply data masking techniques to different types of data, or data storage locations, as appropriate.

Error handling Errors shall be handled securely. Where errors occur, information about the error, and sensitive information such as account and system details, shall not be disclosed in inappropriate ways, such as being displayed back to the user, or included in logs.
Logging Logging should contain the relevant event data such as validation failures, system exceptions, unexpected changes to data, copying and export of sensitive information, etc. Log data should also be protected from unauthorised access in line with our Information Systems Security Policy.
File management Parameter and validation checks should be set for the management of files to prevent upload of unauthorised or unexpected files, etc.
Threat modelling Assists with analysing application components, and identifying and categorising possible threats and requirements for mitigation. This shall also assist in determining security and privacy testing for the service or application so as to proactively secure data and prevent risks from occurring.
Data lifecycle protection Mechanisms for the protection of data shall be implemented with consideration for the full lifecycle of the data to ensure it is appropriately protected from the point of collection to destruction.

2.3 Secure Development

When carrying out development activities, developers shall not only ensure that the security requirements identified from the design stage are implemented in the development stage, but that necessary security controls are applied to protect the development process and the development environment. Secure development requirements include, but are not limited to:

  • Ensuring that application, development, and system architecture is secure, including appropriate network, access, and asset protection controls as documented in our Information Systems Security Policy.
  • Ensuring that changes are controlled in line with our documented Change Control Procedure.
  • Establishing approved procedures for development which includes controlled workflows, secure code review, acceptance testing, and providing appropriate developer training.
  • Ensuring that third-party code such as open-source software is not modified or changed unless it is considered necessary. Modifications to third-party code may introduce unexpected vulnerabilities, and may not be permitted by the third-party.
  • Ensuring logging and monitoring is implemented in line with our Information Systems Security Policy.
  • Ensuring all necessary information such as system configuration data, code, test data, etc. is identified and backed up in line with our Backup and Recovery Policy & Procedure.
  • Ensuring that access to source code is appropriately restricted in line with access control policies documented in our Information Systems Security Policy. Restricting access to source code shall also include ensuring appropriate access controls are enforced for the development tools and software libraries used to manage and produce the source code. Where required, developed source code may be held in escrow.
  • Ensuring that development, test, and production environments are separated. Where the environments are not properly separated, differences in access and change control procedures between them may result in vulnerabilities being introduced.
  • Ensuring that data used for development and testing purposes is either sanitised or protected in line with data protection requirements. Where live/production data is used in a development or test environment, the data may become accessible to persons who would not normally be authorised to view the data, resulting in potential data breach. Also, where a test or development environment may be compromised due to an undiscovered security weakness, this may lead to a breach of the live/production data.

2.4 Testing

To ensure that the identified security controls are implemented correctly, and to reduce the likelihood of security vulnerabilities going undetected, developers shall plan and carry out security testing in the testing stage. Security testing requirements include, but are not limited to:

  • Carrying out secure code review by peers in line with the development process.
  • Carrying out any security testing identified as part of threat modelling exercises in the design stage.
  • Vulnerability scanning of the application to identify known application vulnerabilities and other security vulnerabilities such as open ports, deprecated SSL/TLS certificates, etc.
  • Penetration testing should be conducted bi-annually to ensure thorough examination of the environment for security weaknesses, including but not limited to input validation testing, user enumeration, and system hardening. The results of these penetration tests should be presented to the Chief Technology Officer (CTO), along with a report identifying vulnerabilities and shortcomings revealed by the tests. The CTO is responsible for reviewing these findings and creating a remediation plan to address them. Additionally, the CTO should oversee the implementation of the rectification procedures or actions to ensure the security of the environment is maintained at an optimal level.
  • Carry out appropriate acceptance testing of any new or modified information systems in line with our Change Control Procedure.

2.5 Deployment

When deploying new or modified software services, features, or applications, developers shall ensure that security requirements are built into the deployment stage of the process to protect our information systems and code. Security requirements for deployment include, but are not limited to:

  • Ensuring that secure code review by peers has been performed prior to deployment.
  • Establishing approved procedures for controlling the deployment pipeline which may include approval and code verification controls.
  • Ensuring deployments are made only from trusted code and not pulled from untrusted sources.
  • Ensuring any credentials with elevated privileges used to run code are protected from unauthorised exposure and use.
  • Ensuring required access controls in line with our Information Systems Security Policy are properly implemented to prevent unauthorised access.
  • Ensuring that deployments are not scheduled immediately prior to periods of unavailability, such as weekends or leave. Where unforeseen issues arise as a result of the deployment, resolution times may be impacted due to the unavailability of developers.
  • Ensuring deployments that may impact data security are documented and communicated in line with our Data Handling & Retention Guidelines, where necessary. This will ensure data processing activities remain transparent to users.

3. Outsourced Development

Where it is necessary to outsource development activities to a contractor or third-party provider, our organisation requires that the software, features, and applications developed adhere to our requirements for quality and security. As documented in the communications section of this policy, contractors and third-parties involved in development activities shall be issued with a copy of this document as part of the process for contracting services.

All third-parties involved in development activities shall be managed in line with our Supplier Due Diligence Policy which sets out our requirements for auditing, data agreements, information security controls, technology supply chain, and intellectual property.