Systems Acquisition, Development and Maintenance Policy

1. Purpose

This policy makes security part of the whole life of every information system: from the first statement of requirements, through purchase or build, testing and release, to maintenance, change and retirement. It aims to stop weaknesses from entering systems, to find those that do enter before attackers do, and to make sure that systems process information correctly and protect it throughout.

It applies the principle that security is cheaper and more effective when designed in than when added afterwards, and that every system, bought or built, is accepted into service only with evidence that it is fit to protect the information it handles.

2. Scope

• In scope: all information systems that the Organisation acquires, builds, configures, customises, integrates, hosts or maintains, including internal business applications, customer-facing platforms, websites, mobile apps, application programming interfaces, scripts and automation, databases, infrastructure as code, commercial off-the-shelf software, software as a service, and open-source components.
• In scope: work done by employees, contractors and suppliers, including outsourced development, and changes made to systems after release.
• Out of scope: the general change process (see the Change Management Policy and Procedure), the operation of live systems (see the Communications and Operations Security Policy) and the purchase of non-software items.

Projects of any size are covered. A small project may use the shorter forms of the checklists, but may not skip the controls.

3. Terms and Definitions

4. Roles and Responsibilities

5. Systems Acquisition, Development and Maintenance Policy Statements

5.1 Security Requirements of Information Systems

5.1.1 Security requirements analysis and specification

• Every new system, major enhancement and purchase must start with a record of security requirements, produced with the system owner and reviewed by the Head of IT Security before design or selection is finalised. The record is part of the project documents.
• Requirements are drawn from a risk assessment under the Risk Management Policy, the classification of the information handled, legal and customer contract needs, the Organisation's own policies, and the lessons of past incidents.
• Requirements must be specific and testable (for example, 'lock accounts after [5] failed sign-ins' and not 'strong authentication'), traceable to the test that shows they are met, and updated if the design changes.
• A project may not move from design to build until the security requirements are approved, and may not release until each has been shown to be met or an exception has been approved.

For purchased products, requirements are written into the request for proposal and used to score suppliers. The system owner and the Head of IT Security review supplier evidence such as independent assurance reports, test results, vulnerability handling process and support commitments, and the contract is concluded under the Supplier Relationship Management Policy.

5.1.2 Securing application services on public networks

• Applications that are reachable over the internet or other public networks must use encrypted connections for all traffic, with current protocol versions and certificates from an approved authority, and must not accept unencrypted connections.
• Users and systems that connect must be authenticated. Multi-factor authentication is required for administrative functions and for access to Confidential data.
• Applications must be protected against abuse by input validation, output encoding, request size and rate limits, bot and automated abuse controls, and a web application firewall or equivalent where the system is internet-facing and critical.
• Interfaces (APIs) must be inventoried, authenticated, authorised per call, rate limited and logged. Interfaces not in use are removed.
• Information that is returned to the user must be the minimum necessary. Error messages must not reveal system, path, version or database detail.
• Public-facing applications are tested before release and after significant change by vulnerability scanning and, for critical ones, by penetration testing under the Vulnerability Assessment and Penetration Testing Procedure.
• Contracts with parties whose services form part of the application, such as payment, identity, messaging and hosting providers, carry security, availability and incident-reporting obligations.

5.1.3 Protecting application service transactions

• Transactions are protected against incomplete transmission, mis-routing, alteration, unauthorised disclosure, duplication and replay by using encrypted channels, signed or integrity-checked messages, unique transaction identifiers and time limits.
• Transactions with financial or legal effect require a way to show who initiated them and that they were not altered: a verified identity, an approval step where the value or risk is high, and a record that cannot be altered by the person who made it.
• Transaction data is stored inside the Organisation's controlled environment and not on servers reachable from the public network. Where the Organisation uses a third party to carry out transactions, the agreement defines responsibility for failures and disputes.
• Applications that complete transactions send confirmation to the user and keep an audit trail of the steps, so that disputes and errors can be resolved.

5.2 Correct Processing in Applications

5.2.1 Input data validation

• All input is treated as untrusted, whether it comes from users, files, other systems or devices. It is validated on the server side for type, length, range, format, allowed characters and business rules before use; client-side checks are for convenience only.
• Validation uses allow-lists wherever possible. Input is encoded or escaped for the context in which it is used, and database access uses parameterised queries; dynamic construction of queries or commands from input is forbidden.
• Files uploaded by users are checked for type and size, scanned for malware, stored outside the web root with generated names, and never run.
• Rejected input is logged with enough detail to spot attacks, but without storing secrets or personal data unnecessarily.
• Periodic checks compare data in key fields for duplicates, missing data, out-of-range values, and unauthorised changes, and unusual patterns are investigated.

5.2.2 Control of internal processing

• Applications include checks that detect corruption from processing errors or deliberate acts, such as control totals, batch counts, record sequence checks, balancing of debits and credits, reconciliation between systems and checks on data after migration.
• Processes run in the right order and stop on failure; they do not continue to produce results after an earlier step has failed. Recovery from a failed run is documented and prevents duplicates or omissions.
• Functions that add, change or delete data are protected by access control. Changes to sensitive data are logged with the old and new value, user and time.
• Scheduled jobs run under dedicated service accounts with only the rights needed, and job schedules are changed only through the change process.
• Overflow, division, concurrency, time-out and resource limits are handled safely, and the application fails closed, not open.

5.2.3 Message integrity

• Where messages, files or records pass between systems or to third parties, and an alteration would cause harm, integrity is protected with message authentication, digital signatures or hashes, using methods approved by the Cryptography Policy.
• Keys and certificates used for integrity are managed under the Key Management Process.
• Messages received are checked for integrity and origin before they are acted upon, and failed checks are logged and alerted.

5.2.4 Output data validation

• Outputs of applications, such as reports, files, screens and messages, are checked to confirm that the right data was produced, is complete, and is reasonable in the circumstances.
• Output is classified and labelled, and is made available only to authorised recipients. Reports with Confidential data are restricted by role and logged when exported.
• Reconciliation procedures confirm that outputs agree with the inputs and with the data held. Differences are investigated and resolved by the system owner.
• Outputs that are tested against a defined case before release include examples of boundary, error and abuse cases.

5.3 Security of System Files

5.3.1 Control of operational software

• Software is installed on production systems only by authorised administrators through the change process, from the release of an approved build, after testing and acceptance.
• Production systems run only executable code and approved components. Compilers, development tools and source code are not kept on them.
• Vendor-supported versions are used. Software that is no longer supported is recorded as a risk, protected by compensating controls, and replaced to a plan approved by senior management.
• A roll-back plan and a copy of the previous working version of software and configuration are kept for each release, for at least [the last 3 releases].
• Every release is logged with version, date, approver, hash or signature of the build, and the people involved.
• Software provided by suppliers is patched in line with the Patch Management Policy. Before a supplier patch is installed, it is tested in a non-production environment, unless the risk of delay is greater and the Head of IT Security approves.
• Live data must never be used in test and development environments except under the test data rules in this policy. Systems and applications used for emergency repair are time-limited and recorded.

5.3.2 Access control to program source code

Source code owned by customers is kept in repositories separated from the Organisation's own and accessed only by those working on that customer's project. Printouts or exports of source code outside repositories are not permitted unless the information owner approves.

5.4 Security in Development and Support Processes

5.4.1 Secure development policy

• Every project that builds software follows a secure development lifecycle, with these security activities and gates: requirements and risk assessment; threat modelling and security design review; secure coding with the standard and checklists; peer code review; automated static analysis and secret scanning at each commit; software composition analysis at build; dynamic testing and, for critical systems, penetration testing before release; security acceptance; and post-release monitoring.
• The Organisation keeps a secure coding standard covering input handling, authentication and session management, access control, cryptography, error handling and logging, data protection, file handling, and the use of third-party code. It is reviewed [every 12 months] and when new classes of attack emerge.
• Developers receive secure development training when they join and [annually] after that, with role-specific training for architects, testers and administrators of build tools.
• Defects found in security testing are rated, assigned and fixed within the periods in the table below, or the risk is accepted in writing by the system owner and the Head of IT Security.

5.4.2 System change control procedures

• Changes to systems in the development lifecycle follow the Change Management Policy and Procedure and the System Development and Maintenance Procedure. They are recorded, assessed for security impact, tested, approved and reviewed after release.
• Changes to application code are made in branches, reviewed, tested automatically, and promoted through environments in order. Direct changes to production code or configuration are not allowed.
• Changes which alter security functions (authentication, authorisation, logging, encryption) or which add a new interface, data store or third party, always receive a security review.
• Documentation, including diagrams, risk records and operating instructions, is updated as part of each change, and a change is not complete until this is done.
• Version control and release records allow the Organisation to identify exactly which code and configuration is in production at any time.

5.4.3 Technical review of applications after operating system changes

• When an operating system, database, runtime, platform or middleware changes, including patches and version upgrades, the owners of the applications that depend on them test those applications before the change goes to production, to make sure security and function are not harmed.
• The change plan lists the applications affected. Testing covers authentication, access control, integrity checks, logging and interfaces as well as function.
• The application owners and the platform owners agree test windows and the timetable early, so that urgent security patches are not delayed and so that applications are not left on unsupported platforms.
• Failed or deferred application tests are recorded as risks with an owner and date; a deferred urgent patch needs the approval of the Head of IT Security.

5.4.4 Restrictions on changes to software packages

• Purchased packages are used as supplied wherever possible. Modifying the package needs the system owner's approval and a review of the security, support and licence consequences.
• Where modification is allowed, the original is kept, the changes are recorded and tested, and a plan exists for applying the supplier's later updates; or configuration, extensions or separate add-ons are used in place of changes to the core code.
• The supplier's consent is obtained where the contract requires it, and the effect on warranties and support is recorded.
• Packages with built-in default accounts, sample content and debug features have them removed or disabled before use.

5.4.5 Secure system engineering principles

Architects record how these principles are applied in the design document. Principles are applied to new systems, to changes to existing systems, and to systems outsourced to others.

5.4.6 Prevention of information leakage

• Developers and testers must not paste production data, customer data, source code or secrets into public or unapproved tools, including online code-sharing, question-and-answer, conversion and AI services, as set out in the Employee AI Usage Policy.
• Source code, build outputs, debug files, backups and logs are not placed in public locations. Automated scans look for exposed secrets and public repositories bearing the Organisation's name.
• Applications do not write secrets or personal data to logs, error messages, URLs, analytics tools or crash reports.
• Hidden channels (such as covert data in unused fields, metadata or timing) are considered for systems that handle highly sensitive data, and data loss prevention controls are applied at the boundary.
• Staff who leave the project have access removed the same day, and contractors sign confidentiality undertakings before they are given code.

5.4.7 Secure development environment

• Environments for development, build, test and staging are separate from production, with their own accounts and networks, and are protected in proportion to the sensitivity of the code and data they hold.
• Access to development environments needs authentication, role-based permissions and logging. Developer devices follow the Acceptable Usage Policy and the Secure Configuration Policy and are encrypted.
• Development tools, plug-ins and libraries come from approved sources and are kept up to date. The build service is hardened and its logs are kept.
• Backups of code, configuration and pipeline definitions are taken and tested under the Backup and Restoration Policy.
• Transfer of data and code between environments is controlled. Moving anything from production to a development or test environment follows the test data rules.
• Remote work on development environments is through the approved VPN or virtual desktop, never from unmanaged devices.

5.4.8 Outsourced software development

• Before work starts, outsourced developers are assessed under the Supplier Relationship Management Procedure, and the contract states: ownership of code and intellectual property, licensing, escrow where needed, the secure coding standard to be followed, the testing and evidence to be provided, right to audit and to review code, personnel screening, confidentiality, handling of data, incident reporting, subcontracting limits, and exit and return of materials.
• Outsourced developers work in the Organisation's repositories and environments where possible, or in segregated, assessed environments with access limited to the project.
• The Organisation reviews or tests delivered code for security (by scanning, code review of sensitive parts and testing) before accepting it, and does not rely only on the supplier's assurance.
• Acceptance is not given until the evidence is complete and the findings are resolved. Warranties and support after delivery are agreed for the period set in the contract.

5.4.9 System security testing

Testers must be independent of those who wrote the code for high-risk systems. Results are retained as evidence and findings are tracked to closure.

5.4.10 System acceptance testing

• Acceptance tests are planned with the system owner and run in an environment which resembles production. They cover function, performance, security, usability, recovery and interfaces.
• The system owner records the decision to accept or reject using the sign-off form in Annexure B, with the Head of IT Security signing for security. Release to production needs the approval of the change manager under the change process.
• Acceptance tests are repeated for major changes. Results, defects and decisions are kept with the project documents.
• A system is not accepted if critical or high security defects are open unless the risk has been accepted in writing, with an owner and an end date.

5.5 Test Data

5.5.1 Protection of test data

1. Live production data should not be used for development or testing. Where possible, synthetic data is generated, or live data is masked or anonymised so that individuals, credentials and secrets cannot be recovered.
2. Where the use of live data cannot be avoided, a request in the form of Annexure C is approved by the information owner, the privacy lead and the Head of IT Security, naming the data, the purpose, who may use it, where it will be, and when it will be deleted.
3. Live data in test environments is protected like production: access control, encryption, logging, and network separation. It is held only for the test period, and deleted and verified afterwards, with the date recorded.
4. Copying live data is logged, and the data is never copied to personal devices, public tools or environments not approved for it.
5. Customer data may be used in test only with the permission of the customer, as the contract requires, and personal data must be treated according to the Data Protection and Privacy Policy and applicable law.
6. Test data and test accounts must be removed before a system goes into production. The security team scans for leftover test accounts, sample data and credentials as part of release checks.

5.6 Acquisition of Systems and Services

• Before a system, package or service is bought, the system owner states the need, the information it will hold and the risk, and consults the Head of IT Security. Selection includes the security requirements in section 5.1.1.
• Suppliers are assessed under the Supplier Relationship Management Procedure, covering their security practices, secure development, vulnerability disclosure and patching, certification or independent assurance, data location, subcontractors and exit terms.
• The Organisation examines the licence, support and update commitments, and the cost of leaving the product, before agreeing. Products that cannot be updated or are close to the end of support are not chosen unless there is a plan to replace them.
• Cloud services are acquired under the Cloud Computing Security Policy and Procedure.
• Software is installed from the vendor's official source, with the integrity of the download checked.
• Acceptance testing and security testing are done before a bought system goes into use, and default accounts and settings are changed.

5.7 Maintenance and Retirement

• Every system has a named owner and a maintenance plan, including patching under the Patch Management Policy, review of components and licences, and contact details for the supplier's support.
• Vulnerabilities in third-party components are tracked. Where an update cannot be applied within the period in the Patch Management Policy, a mitigation and a date for the fix are recorded.
• A register of systems and their end-of-support dates is reviewed [every 6 months], and replacement or migration is planned at least [12 months] before support ends.
• When a system is retired, access is removed, interfaces are closed, data is moved, archived or deleted according to the retention rules, media is sanitised under the Asset Disposal Process, licences and domain names are released, and records are updated. The system owner signs off the retirement.
• Source code and documentation for retired systems that must be kept for legal or customer reasons are archived with controlled access.

6. Compliance and Monitoring

Results are included in the report to senior management in the management review.

7. Records and Evidence

Records are protected from change and are made available to auditors, and to customers where the contract requires.

8. Where the Detail Is Kept

• System Development and Maintenance Procedure: the steps for each stage of the lifecycle, with gates and forms.
• Change Management Policy and Procedure: approval, testing and release of changes.
• Secure Configuration Policy: the hardening standards used for systems and environments.
• Cryptography Policy and Key Management Process: encryption, integrity and key handling.
• Vulnerability Assessment and Penetration Testing Procedure and Patch Management Policy: testing, findings and patch times.
• Supplier Relationship Management Policy and Procedure: assessment and contracts for suppliers.
• Data Protection and Privacy Policy and Procedure: privacy requirements and assessments.
• Communications and Operations Security Policy: how live systems are operated.

Annexure A: Security requirements checklist

Annexure B: Security acceptance and release sign-off

Annexure C: Test data request

Annexure D: Source code access register

Annexure E: Third-party package and component assessment

9. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

10. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

11. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• System Development and Maintenance Procedure
• Change Management Policy and Procedure
• Secure Configuration Policy
• Cryptography Policy
• Vulnerability Assessment and Penetration Testing Procedure
• Patch Management Policy
• Supplier Relationship Management Policy
• Data Protection and Privacy Policy