System Development and Maintenance Procedure

Template draft. Replace everything in [square brackets] with your own decision, delete what does not describe what you really do, and approve it through your own document control. It is not legal advice and does not make an organisation compliant or certified.

1. Purpose

This procedure defines the stages a system passes through from idea to retirement, and the security activities, evidence and approvals required at each stage. It gives engineering teams a repeatable path so that security requirements are set before design, tested before release and maintained after go-live.

Build security into every stage so defects are found early, when they are cheapest to fix.
Separate duties so that nobody can write, approve and release their own change without independent review.
Keep an auditable trail from requirement to code, test result, approval and deployed version.

2. Scope and Applicability

The procedure applies to all systems the Organisation develops, configures, extends or has developed for it, whether built in-house or by a supplier, and whether hosted on premises, in a cloud service or on customer-facing platforms.

In scope: new applications, services and APIs; major enhancements; infrastructure as code; scripts and automation that touch production; database changes; mobile and web front ends; low-code and configuration-driven tools; and open-source components included in any of these.
In scope people: developers, architects, testers, DevOps and release engineers, product owners, security reviewers, and supplier staff doing development for the Organisation.
Out of scope: off-the-shelf software installed without modification (see the Supplier Relationship Management Procedure and the Patch Management Procedure), and personal productivity spreadsheets that hold no Organisation data of classification above Internal.
Where a system is developed using an agile or iterative method, the stages still apply; they are completed per increment rather than once, and the evidence is recorded for each release.

3. Terms and Definitions

The glossary at the end of this procedure defines the technical terms used. The terms below are central to how the stages operate.

Term	Meaning
Security gate	A mandatory checkpoint at the end of a stage where named evidence is reviewed before work may proceed.
Environment	A separated set of infrastructure for one purpose: development, test, staging or production.
Release candidate	A build that has passed all automated checks and is proposed for deployment.
Change	Any addition, modification or removal that could affect a production service; governed by the Change Management Procedure.
Technical debt	Known shortcuts or defects in the system that increase future cost and risk, recorded in the backlog.
Definition of done	The agreed list of activities, including security activities, that must be complete before work is accepted.

4. Roles and Responsibilities

Role	Responsibilities
Document owner (Head of Engineering)	Maintains this procedure, the secure development standards and the gate checklist; reports compliance to management.
Product owner	Defines business and security requirements with security, accepts release into production, and owns the risk of the system.
Solution architect	Produces the design and threat model, and enforces secure architecture principles.
Developers	Write code to the secure coding standard, perform peer review, fix defects and keep dependencies current.
Test lead	Plans and runs functional, regression, performance and security testing, and reports results against acceptance criteria.
Security reviewer	Reviews requirements, designs, scan results and exceptions, and signs the security gates.
Release manager	Controls the release pipeline, checks approvals and deployment evidence, and manages rollback.
Operations team	Operates production, applies patches and monitors the system after release.
Information security team	Provides tools, standards and guidance, and performs independent assurance.

Activity	Responsible	Accountable	Consulted	Informed
Security requirements specification	Product owner	Head of Engineering	Security reviewer	Test lead
Architecture and threat model	Solution architect	Head of Engineering	Security reviewer	Developers
Secure coding and peer review	Developers	Head of Engineering	Security reviewer	Product owner
Security testing and defect closure	Test lead	Head of Engineering	Security reviewer; Developers	Product owner
Approval for production release	Release manager	Product owner	Security reviewer; Operations team	Service desk
Patching and maintenance	Operations team	Head of IT	Developers; Security reviewer	Product owner
Retirement and data disposal	Operations team	Product owner	Information security team	Legal and compliance

5. System Development and Maintenance

Every system follows the seven stages below. A project may not skip a stage; for small changes the activities are scaled down but the gate evidence is still recorded in the ticketing tool. The security gates for all stages are summarised in the table at the end of this section.

5.1 Planning stage

Planning decides what will be built, why, by whom and how risk will be controlled. The output is an approved project record with security embedded from the start.

InitiateThe product owner raises a request with business objective, users, data types and the highest classification of data involved. Target: complete before funding is approved.
AssessInformation security performs a security and privacy screening using the Risk Management Policy; if personal data is processed at scale, a privacy impact assessment is started under the Data Protection and Privacy Procedure.
ScopeDefine security, availability, performance and compliance requirements, including legal duties in each jurisdiction where the system will operate.
PlanAgree timeline, environments, team, tools and licences; identify third parties and start supplier due diligence under the Supplier Relationship Management Procedure.
ApproveThe steering group approves the plan; security gate G1 is signed by the security reviewer within [5 working days] of submission.

Output: project charter, security requirements baseline, risk register entries, resource plan.

5.2 Designing stage

Design turns requirements into an architecture and detailed specification that can be reviewed for weaknesses before any code is written.

ArchitectThe solution architect documents components, trust boundaries, data flows, storage, interfaces and hosting, applying least privilege, defence in depth, fail-safe defaults and separation of duties.
Model threatsRun a threat model using the STRIDE categories on every new system and every major change; record threats, ratings and chosen controls. Reuse the Product Risk Assessment Procedure worksheet.
Specify controlsChoose authentication, authorisation, session handling, input validation, encryption (following the Cryptography Procedure), logging, error handling and secrets management patterns.
Design dataDefine data classification, retention, masking for non-production use, and deletion; avoid collecting data that is not needed.
ReviewHold a design review with the security reviewer; unresolved high-rated threats block gate G2.

Design principle	What the design must show
Least privilege	Each component, service account and user role holds only the permissions needed, with the role matrix attached to the design.
Defence in depth	At least [two] independent controls protect each high-value asset, for example network segmentation and application authorisation.
Secure defaults	A new account, feature or integration starts with the most restrictive setting and is opened up deliberately.
Fail safely	When a check fails or a dependency is down, access is denied and no sensitive detail is shown.
Separation of duties	No single person can both create and approve a sensitive transaction or release.
Minimise attack surface	Unused endpoints, ports, libraries and features are left out; every external interface is listed and justified.
Complete mediation	Every request to a protected resource is checked, not only the first one in a session.
Keep it simple and reuse	Approved shared components for login, logging and encryption are used instead of custom versions.

Note. Designs must show how the environments are separated and how production data is kept out of development and test, unless masked or anonymised.

5.3 Building and coding stage

Developers build to written standards in a controlled, separate environment, and every change is traceable to a ticket.

Source code is held in a central version-control system with access by named users, multi-factor authentication, and branch protection on the main branch; direct commits to the main branch are blocked.
Every change is peer reviewed by at least [one] developer who did not write it, using the code review checklist (Annexure B); security-sensitive changes require a security reviewer.
The secure coding standard must be followed: validate and encode all input and output, use parameterised queries, avoid hard-coded secrets, handle errors without revealing internals, and use approved cryptographic libraries only.
Secrets, keys and tokens are stored in a secrets vault, never in source code, configuration files or tickets; scanners check every commit for them.
Automated checks run on every commit: static analysis, dependency and licence scanning, and secret detection. Findings rated High or above stop the build.
Open-source and third-party components are drawn only from approved repositories, pinned to versions, and listed in a software bill of materials kept for each release.
Developers receive secure coding training at joining and every [12 months]; developers working on high-risk systems are trained in the specific language and framework.
Outsourced development follows this stage and is governed by contract clauses on code ownership, review rights, and delivery of source and build instructions.

5.4 Testing stage

Testing proves that the system meets requirements and resists attack before it reaches users. Testing is done in a test environment that mirrors production but holds no live data.

Plan testsThe test lead writes a test plan covering functional, integration, regression, performance, accessibility and security tests, traced to requirements.
Prepare dataUse synthetic or masked data; production data may be used only with written approval from the data owner and the same controls as production.
RunExecute tests; record each defect with severity, owner and target date in the ticketing tool.
Test securityRun dynamic application testing and, for Critical and High systems, a manual penetration test as set out in the Vulnerability Assessment and Penetration Testing Procedure. Review authentication, authorisation, input handling and logging.
AcceptThe product owner and test lead sign user acceptance. Gate G4 passes only when no open Critical or High security defect remains, or an accepted-risk record exists.

Defect severity	Examples	Rule at release	Target fix time
Critical	Authentication bypass, remote code execution, exposure of restricted data	Release blocked	[3 working days]
High	Broken access control, stored injection, weak encryption of sensitive data	Release blocked unless accepted by the Head of Information Security	[10 working days]
Medium	Missing security header, verbose errors, weak session timeout	Release allowed with a dated fix plan	[30 days]
Low	Cosmetic or best-practice gaps without direct exploit	Release allowed	[Next planned release]

Test information is protected and deleted when testing ends; test accounts are removed before go-live.
Where an audit or assurance activity needs to test live systems, the test is scheduled and agreed so that it does not damage production.

5.5 Deployment stage

Deployment moves a tested build into production under change control, in a way that can be reversed.

PrepareRelease manager confirms the release candidate, software bill of materials, test evidence and rollback plan, and raises a change under the Change Management Procedure.
ApproveApprovals required: product owner, security reviewer (gate G5) and change authority; emergency releases follow the emergency path and are reviewed afterwards within [2 working days].
HardenApply the baseline from the Secure Configuration Policy: remove default accounts, close unneeded ports, set production secrets and enable logging and monitoring.
DeployUse the automated pipeline from a protected branch; no manual changes by individuals to production outside the pipeline except under break-glass access, which is logged and reviewed.
VerifyRun smoke tests, confirm monitoring and alerts, and check for new vulnerabilities in the deployed version. Target: verification complete within [2 hours] of release.
InformNotify users, support and customers where needed and update documentation and the asset register.

Developers do not have standing write access to production. Access to production is given to the operations team and release pipeline, and developer support access is time-limited and approved case by case.

5.6 Maintenance stage

After go-live the system is kept secure and fit for purpose until it is retired. Maintenance is not a lower-priority activity: it is where most real-world vulnerabilities are met.

Maintenance change type	Description	Approval	Gate evidence
Standard	Low-risk, repeatable and pre-approved, such as a routine library patch with passing tests	Pre-approved by change authority	Pipeline results and peer review
Normal	Feature, configuration or data change with an assessed risk	Change authority and security reviewer for High risk	Full G3 to G5 evidence
Emergency	Urgent fix to restore service or close an exploited weakness	Emergency change approver, then review within [2 working days]	Abbreviated record, completed afterwards
Major	Changes to architecture, data flows or trust boundaries	Return to design with new threat model	G2 repeated

Patch and update operating systems, runtimes, libraries and frameworks according to the Patch Management Procedure: Critical within [7 days], High within [30 days], Medium within [90 days].
Review dependency alerts at least [weekly] and treat any Critical alert on an internet-facing system as an incident to triage within [1 working day].
Run vulnerability scans after significant changes and at the frequency set by the Vulnerability Assessment and Penetration Testing Procedure.
Maintenance changes follow the same stages in proportion: minor fixes may use a shortened path with peer review, automated tests and security gate G5; changes that alter architecture or data flows return to design.
Monitor logs, performance and capacity, and review alerts daily; trends feed the capacity and problem processes.
Record defects found in production and perform root cause analysis for any security defect rated High or above; add the missed test to the regression suite.
Review user access, service accounts and secrets used by the system every [quarter].
Back up the system and test restoration according to the Backup Management and Retention Procedure.
Review support arrangements and supplier support end dates annually; plan migration at least [12 months] before a product reaches end of support.

5.7 Retirement

DecideThe product owner approves retirement and records the reason and date.
MigrateMove needed data to the new system or archive it under the retention schedule; confirm completeness.
RemoveRevoke accounts and network paths, delete or archive source code, and cancel licences and domain names.
DisposeSanitise or destroy storage and infrastructure using the Asset Disposal Process and keep the certificate.
CloseUpdate the asset register, remove monitoring and record closure with the security reviewer.

Unattended legacy systems with no owner are a common source of breaches; the register of systems is reviewed every [6 months] for systems with no change activity.

5.8 Governance

Governance ensures that the procedure is followed and that exceptions are visible. Gates are reviewed by people who are independent of the team being gated.

Gate	Stage	Evidence required	Signed by	Target time
G1	Planning	Charter, risk screening, security and privacy requirements baseline	Security reviewer	[5 working days]
G2	Design	Architecture, data flow diagram, STRIDE threat model, design review minutes	Security reviewer	[5 working days]
G3	Build	Code review records, static analysis and dependency scan results, secrets scan, bill of materials	Head of Engineering	[2 working days]
G4	Test	Test report, dynamic scan, penetration test for Critical and High systems, defect closure	Test lead and security reviewer	[5 working days]
G5	Deployment	Change record, rollback plan, hardening checklist, approvals	Release manager and product owner	[1 working day]
G6	Maintenance	Patch compliance report, scan results, access review	Operations team lead	[Quarterly]
G7	Retirement	Data migration or archive proof, access removal, disposal certificate	Product owner	[10 working days]

The Head of Engineering reports gate performance, open exceptions and defect trends to the information security steering group every [quarter].
Internal audit samples at least [five] releases a year across the gates, covering evidence, separation of duties and approvals.
Standards are reviewed when a significant incident, new technology or new legal requirement changes the risk.
Exceptions to a gate are recorded with the risk, compensating control, owner and expiry date, and approved by the Head of Information Security; no exception lasts longer than [90 days].

6. Security Requirements Catalogue

Product owners select from this catalogue when writing requirements at the planning stage. Items marked as baseline apply to every system; others apply where the stated condition is true.

Area	Requirement	Applies
Identity	Users authenticate through the central identity service; multi-factor authentication for administrators and for any external access to restricted data.	Baseline
Authorisation	Role-based access, enforced on the server for every request, with administrative functions separated from user functions.	Baseline
Input and output	All input validated for type, length and range; output encoded for its context; file uploads checked for type and size and stored outside the web root.	Baseline
Sessions	Session tokens are random, expire after [30 minutes] idle, and are invalidated on logout and password change.	Web and mobile
Cryptography	TLS for all transport; sensitive data encrypted at rest; algorithms and keys per the Cryptography Procedure and Key Management Process.	Baseline
Logging	Log authentication events, access to restricted data, administrative actions and errors without storing passwords or full card or identity numbers; protect and retain logs per the Logging and Monitoring Procedure.	Baseline
APIs	Each API call authenticated and authorised; rate limits and request size limits applied; schemas validated; versions retired on a schedule.	Systems with APIs
Privacy	Collect only needed personal data; provide ways to meet rights requests; mask or tokenise in non-production.	Personal data processed
Availability	Recovery time and recovery point targets documented and tested; capacity monitored.	Critical and High systems
Third-party code	Only approved, current components; licence compatibility checked.	Baseline
Mobile and client	No secrets in the client; certificate validation enforced; local storage encrypted.	Mobile and desktop clients

7. Pipeline and Release Controls

Automated pipelines are the only route to production. Their own security is therefore part of the system's security.

Control	Requirement	Evidence
Pipeline access	Only named maintainers change pipeline definitions, with peer review and multi-factor authentication.	Repository permissions report
Build integrity	Builds run on managed, ephemeral runners; artefacts are signed and stored in a protected registry.	Signature check in deployment step
Credentials	Pipeline secrets are short-lived, scoped to one environment and rotated every [90 days].	Secrets vault audit log
Quality gates	Tests, static analysis, dependency scan and secret scan must pass; overrides are logged and approved by the security reviewer.	Pipeline run history
Promotion	Promotion from test to production uses the same artefact; it is never rebuilt.	Artefact hash comparison
Deployment record	Every deployment records version, approver, time and change reference automatically.	Deployment log
Rollback	A tested rollback exists for each release and is exercised at least [twice a year] on Critical systems.	Rollback test record

Infrastructure as code follows the same review and scanning as application code, and plans are reviewed before they are applied.
Low-code and configuration platforms are treated as development: they need an owner, access control, an approval step and a record of changes, and may not be used to process Restricted data until they have passed a security review.
Documentation, including architecture, runbooks and API descriptions, is updated before a release is closed, and reviewed at least [every 12 months] for Critical systems.

8. Environment Separation and Test Data

Development, test, staging and production are kept apart so that experiments, test data and unreviewed code cannot reach live information.

Environment	Purpose	Who may change it	Data allowed
Development	Building and unit testing	Developers	Synthetic data only
Test	Integration, security and acceptance testing	Test lead and pipeline	Synthetic or masked data
Staging	Final rehearsal on production-like setup	Release manager and pipeline	Masked data; production copies only with written approval
Production	Live service	Pipeline and operations team	Live data

Network paths between environments are blocked by default; only the pipeline may promote builds from one environment to the next.
Credentials and keys are different in each environment and never reused.
Production data used for testing, where approved, is masked, access-limited and deleted within [30 days] of the test ending.
Developers do not hold production credentials; production access for investigation is time-limited, approved and logged.

9. Outsourced and Third-Party Development

Where a supplier writes or maintains code for the Organisation, the supplier must follow the stages in this procedure or demonstrate an equivalent. The contract, agreed under the Supplier Relationship Management Procedure, must cover the following.

Ownership of code and deliverables, and delivery of full source, build scripts and documentation at each release.
Right for the Organisation to run its own code review, scan and penetration test before acceptance, and to receive the supplier's test evidence.
Secure coding obligations, named developers cleared by the Organisation, and prompt notice of vulnerabilities discovered.
Escrow or equivalent protection for critical bespoke software if the supplier fails or the relationship ends.
Warranty and defect-fix period of at least [90 days] after acceptance, and a commitment to fix security defects within the times in the defect severity table.

10. Measures

Measure	Target	How it is measured
Releases that passed every required gate	[100 percent]	Release records against gate checklist
Critical and High defects open at release	[0] unless accepted	Defect tracker at gate G4
Code changes with peer review	[100 percent]	Version-control branch report
Critical dependency vulnerabilities fixed within [7 days]	[95 percent]	Dependency scanner report
Developers with current secure coding training	[100 percent]	Training records
Production changes made outside the pipeline	[0]	Change log reconciled with deployment log
Emergency releases reviewed within [2 working days]	[100 percent]	Post-implementation review records

11. Records and Evidence

Record	Kept by	Location	Retention
Project charter and requirements	Product owner	Document management system	Life of system plus [3 years]
Design, data flow and threat model	Solution architect	Document management system	Life of system plus [3 years]
Code review and scan results	Developers	Version-control and pipeline tools	[2 years]
Test plans, results and acceptance	Test lead	Test management tool	[3 years]
Release approvals and change records	Release manager	Ticketing tool	[3 years]
Exception and accepted-risk records	Security reviewer	Risk register	Until expiry plus [3 years]
Disposal certificates	Operations team	Document management system	[7 years]

12. Glossary

Term	Meaning
API	Application programming interface: a defined way for programs to talk to each other.
Authentication	Proving who a user or system is.
Authorisation	Deciding what an authenticated user or system may do.
Backlog	The ordered list of work waiting to be done by a team.
Baseline	An approved configuration or document version used as a reference.
Branch protection	Rules in version control that require review and passing checks before changes are merged.
Build	The act or result of turning source code into a runnable package.
CI/CD	Continuous integration and continuous delivery: automated pipelines that build, test and release changes.
Code review	Examination of code by someone other than its author to find faults and improve quality.
Container	A packaged, isolated runtime for an application and its dependencies.
Dependency	Third-party code or library that a system needs to work.
Dynamic testing	Testing a running application by sending it requests, as an attacker would.
Encryption	Transforming data so that only holders of the right key can read it.
Hardening	Reducing attack surface by removing unneeded features and tightening settings.
Infrastructure as code	Defining servers and networks in versioned files that are deployed by tools.
Least privilege	Giving only the access needed for a task and no more.
Peer review	Review by a colleague of equal standing.
Regression test	A test that checks that existing behaviour still works after a change.
Rollback	Returning a system to its previous working version.
Sandbox	An isolated environment where code can run without affecting real systems.
Software bill of materials	A list of the components and versions inside a software release.
Static analysis	Automated inspection of source code for weaknesses without running it.
STRIDE	A method that sorts threats into Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege.
Threat model	A structured description of how a system could be attacked and what controls address each threat.
Version control	A system that records changes to files and lets teams work on them together.
Vulnerability	A weakness that could be used to harm a system or its data.

Annexure A: Security gate checklist

Gate	Check	Pass / Fail	Evidence reference	Signed by and date
G1	Security and privacy requirements recorded
G2	Threat model complete and high threats addressed
G3	All commits reviewed; no High scan finding open
G4	No Critical or High defect open; acceptance signed
G5	Change approved; rollback tested; hardening done

Annexure B: Code review checklist

Area	Question	Yes / No / n/a
Input	Is all external input validated and output encoded?
Access	Are authentication and authorisation checks present on every sensitive path?
Secrets	Are secrets absent from the code and configuration?
Data	Is personal data minimised, protected and logged only where needed?
Errors	Do errors avoid exposing internal details?
Dependencies	Are new libraries approved, pinned and scanned?
Tests	Are tests added or updated, including a negative test?

Annexure C: Exception and accepted-risk form

Field	Entry
System, release and ticket reference
Gate and requirement not met
Risk description and rating
Compensating controls
Owner and expiry date (not beyond [90 days])
Approved by (Head of Information Security) and date

13. 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.

14. 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.

15. 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

Reference	Title
A.8.25	Secure development life cycle
A.8.26	Application security requirements
A.8.27	Secure system architecture and engineering principles
A.8.28	Secure coding
A.8.29	Security testing in development and acceptance
A.8.30	Outsourced development
A.8.31	Separation of development, test and production environments
A.8.32	Change management
A.8.33	Test information