Introduction: Why A.14 Is the Cornerstone Control for CI/CD
Annex A.14 — System Acquisition, Development and Maintenance — is the single most relevant control domain for organisations operating CI/CD pipelines. It directly governs how systems are developed, changed, tested, and accepted into production. For auditors and compliance officers, A.14 is where you will find the greatest density of CI/CD-specific control requirements and, often, the greatest density of non-conformities.
This deep dive examines every A.14 sub-control in the context of CI/CD pipelines, providing clear guidance on what compliance looks like, what evidence is required, and what constitutes a red flag during audit.
A.14.1 — Security Requirements of Information Systems
A.14.1.1 — Information Security Requirements Analysis and Specification
What it means for CI/CD: Before any system is developed or acquired, security requirements must be defined. In a CI/CD context, this means that security requirements are specified before development begins and are traceable through the pipeline — from requirements definition through to deployment verification.
Evidence demonstrating compliance:
- Security requirements documented in user stories, acceptance criteria, or dedicated security requirement specifications
- Traceability from security requirements to pipeline-enforced test cases
- Records showing security requirements were reviewed and approved before development commenced
What non-compliance looks like: Security requirements are absent, informal, or added retroactively after development. No linkage between stated requirements and automated verification in the pipeline.
A.14.1.2 — Securing Application Services on Public Networks
What it means for CI/CD: Applications deployed through CI/CD pipelines to public-facing environments must have controls for data integrity, confidentiality, and non-repudiation. The pipeline itself must verify that TLS configurations, API security controls, and authentication mechanisms are properly configured before deployment.
Evidence demonstrating compliance:
- Pipeline stages that verify TLS configuration and certificate validity
- Automated checks for security headers and transport security
- Records of security configuration verification prior to public deployment
What non-compliance looks like: Applications deployed to public networks without automated security configuration verification. No pre-deployment checks for transport security.
A.14.1.3 — Protecting Application Services Transactions
What it means for CI/CD: Where applications handle transactions, the pipeline must include verification that transaction integrity controls (complete transmission, routing validation, message integrity, confidentiality) are in place and tested.
Evidence demonstrating compliance:
- Integration test suites covering transaction integrity scenarios executed in the pipeline
- Records of transaction security testing results retained with pipeline execution history
What non-compliance looks like: Transaction-handling applications deployed without integration testing of transaction security controls.
A.14.2 — Security in Development and Support Processes
A.14.2.1 — Secure Development Policy
What it means for CI/CD: The organisation must have a documented policy governing secure development practices. In CI/CD environments, this policy must address automated build and deployment processes, pipeline security controls, and the integration of security testing into the delivery pipeline.
Evidence demonstrating compliance:
- Approved secure development policy explicitly covering CI/CD processes
- Policy review records showing regular updates
- Evidence of policy communication to all pipeline users and administrators
- Training records for personnel involved in pipeline management
What non-compliance looks like: Secure development policy exists but makes no reference to CI/CD pipelines or automated processes. Policy has not been reviewed since CI/CD adoption.
A.14.2.2 — System Change Control Procedures
What it means for CI/CD: This is a pivotal control for CI/CD. All changes to systems must follow formal change control procedures. In CI/CD, the pipeline is the change control mechanism — but it must enforce documented procedures including approval requirements, impact assessment, testing verification, and rollback capability.
Evidence demonstrating compliance:
- Change control procedures that reference the CI/CD pipeline as the enforcement mechanism
- Pipeline configurations showing mandatory approval gates before production deployment
- Audit trails of all changes including who initiated, who approved, what was tested, and deployment outcome
- Evidence that emergency change procedures are defined and followed (with retrospective approval)
What non-compliance looks like: Developers can push changes directly to production bypassing the pipeline. No approval gates in the pipeline. Emergency changes have no retrospective review process.
A.14.2.3 — Technical Review of Applications After Operating Platform Changes
What it means for CI/CD: When the underlying platform changes (operating system updates, middleware upgrades, infrastructure changes), applications must be reviewed and tested. CI/CD pipelines should trigger regression testing when platform dependencies change.
Evidence demonstrating compliance:
- Documented procedure for platform change impact assessment
- Records of regression test executions triggered by platform changes
- Evidence that pipeline base images and platform dependencies are version-controlled with change tracking
What non-compliance looks like: Platform changes are made without triggering application regression testing. No tracking of platform dependency versions in the pipeline.
A.14.2.4 — Restrictions on Changes to Software Packages
What it means for CI/CD: Modifications to vendor-supplied or third-party software packages must be controlled and limited. In CI/CD, this covers modifications to open-source components, forked dependencies, and customised third-party integrations.
Evidence demonstrating compliance:
- Policy defining when third-party package modification is permitted
- Approval records for any modifications to third-party packages
- Pipeline controls that detect and flag modified packages (integrity verification, checksum validation)
- Vendor notification and support impact assessments for modified packages
What non-compliance looks like: Third-party packages are routinely forked or modified without formal approval. No integrity checking in the pipeline for package modifications.
A.14.2.5 — Secure System Engineering Principles
What it means for CI/CD: The organisation must establish, document, and apply secure engineering principles to all system development. The CI/CD pipeline should enforce these principles through automated checks — architecture reviews, security pattern validation, and compliance verification.
Evidence demonstrating compliance:
- Documented secure engineering principles applicable to CI/CD-delivered systems
- Pipeline-enforced checks that validate adherence to engineering principles
- Architecture review records for new systems entering the pipeline
- Evidence that secure engineering principles are reviewed and updated periodically
What non-compliance looks like: Secure engineering principles exist on paper but are not enforced through the pipeline. No automated verification of security architecture patterns.
A.14.2.6 — Secure Development Environment
What it means for CI/CD: Development environments — including CI/CD build environments — must be secured and protected. Build agents, artifact repositories, and pipeline orchestration platforms are development environments that require appropriate security controls.
Evidence demonstrating compliance:
- Security controls applied to CI/CD build environments (network segmentation, access control, hardening)
- Evidence of build environment isolation (ephemeral build agents, container isolation)
- Access control records for development and build infrastructure
- Hardening standards applied to CI/CD platform infrastructure
What non-compliance looks like: Build environments share infrastructure with production without isolation. Build agents are long-lived with accumulated state and no periodic rebuilding. No hardening standards for CI/CD infrastructure.
A.14.2.7 — Outsourced Development
What it means for CI/CD: When development is outsourced, the organisation must supervise and monitor the activity. In CI/CD, this means outsourced developers must use the organisation’s pipeline (not their own), and their contributions are subject to the same automated controls and approval processes.
Evidence demonstrating compliance:
- Contractual requirements for outsourced developers to use the organisation’s CI/CD pipeline
- Access control records showing outsourced developers have appropriate (limited) pipeline access
- Evidence of code review requirements for outsourced contributions
- Monitoring records for outsourced developer pipeline activity
What non-compliance looks like: Outsourced developers use their own build and deployment processes. Outsourced contributions bypass standard pipeline controls or code review requirements.
A.14.2.8 — System Security Testing
What it means for CI/CD: Security testing must be performed during development. CI/CD pipelines should integrate automated security testing — static analysis, dependency vulnerability scanning, dynamic testing — as mandatory pipeline stages that cannot be bypassed.
Evidence demonstrating compliance:
- Pipeline configurations showing mandatory security testing stages
- Security test results retained with each pipeline execution
- Evidence that security test failures block progression to production
- Records of security testing tool updates and rule maintenance
What non-compliance looks like: Security testing exists but is optional or advisory only. Test results are not retained. Security test failures can be overridden without documented justification.
A.14.2.9 — System Acceptance Testing
What it means for CI/CD: Acceptance testing programmes and criteria must be established. The CI/CD pipeline must enforce acceptance criteria before deployment to production — including functional, performance, and security acceptance gates.
Evidence demonstrating compliance:
- Defined acceptance criteria for each deployment stage
- Pipeline configurations enforcing acceptance gates
- Records of acceptance test results for each production deployment
- Evidence that acceptance criteria are reviewed and approved by appropriate stakeholders
What non-compliance looks like: No formal acceptance criteria defined. Pipeline allows deployment without acceptance verification. Acceptance testing is manual and inconsistently applied.
A.14 Sub-Control Mapping Table
| A.14 Sub-Control | CI/CD Implementation | Required Evidence | Red Flags |
|---|---|---|---|
| A.14.1.1 Security requirements | Security requirements traced to pipeline test cases | Requirements specifications; traceability records; test case mappings | No security requirements defined before development begins |
| A.14.1.2 Public network services | Pre-deployment security configuration checks | Automated TLS and security header verification results | Public deployments without security configuration verification |
| A.14.1.3 Transaction protection | Transaction integrity testing in pipeline | Integration test results covering transaction scenarios | Transaction systems deployed without integrity testing |
| A.14.2.1 Secure development policy | Policy governing CI/CD security practices | Approved policy; review records; communication evidence | Policy does not mention CI/CD; no review since pipeline adoption |
| A.14.2.2 Change control | Pipeline as change control enforcement mechanism | Approval gate configurations; change audit trails; emergency change records | Direct-to-production pushes possible; no approval gates |
| A.14.2.3 Platform change review | Regression testing triggered by platform dependency changes | Platform change records; regression test results | Platform updates without application regression testing |
| A.14.2.4 Package change restrictions | Integrity verification for third-party packages | Package modification approvals; integrity check results | Forked packages without approval; no integrity checks |
| A.14.2.5 Secure engineering principles | Pipeline-enforced architecture and security pattern checks | Documented principles; automated verification results | Principles exist on paper only; no pipeline enforcement |
| A.14.2.6 Secure dev environment | Hardened, isolated build environments | Hardening records; isolation evidence; access logs | Shared infrastructure; persistent build agents; no hardening |
| A.14.2.7 Outsourced development | Outsourced developers use organisation’s pipeline | Contracts; access records; monitoring logs; code review records | External developers bypassing pipeline; no monitoring |
| A.14.2.8 Security testing | Mandatory automated security testing stages | Pipeline configs; test results; tool maintenance records | Optional security tests; results not retained; easy bypasses |
| A.14.2.9 Acceptance testing | Pipeline-enforced acceptance gates | Acceptance criteria; gate configurations; test results per deployment | No acceptance criteria; manual-only testing; inconsistent application |
How A.14 Connects to Other Annex A Controls
A.14 does not operate in isolation. Effective CI/CD governance requires understanding how A.14 intersects with other control domains:
- A.9 (Access Control) — A.14.2.2 change control depends on A.9 access controls to ensure only authorised personnel can approve and trigger deployments. Access control failures undermine the entire change control framework.
- A.12 (Operations Security) — A.14.2.6 secure development environment requirements align with A.12 operational procedures. Logging requirements under A.12 provide the audit trail needed to verify A.14 change control compliance.
- A.15 (Supplier Relationships) — A.14.2.4 package restrictions and A.14.2.7 outsourced development connect directly to A.15 supplier management. Third-party components in the pipeline are both a development concern (A.14) and a supplier risk concern (A.15).
Auditor Verification Checklist for A.14
When auditing A.14 compliance in CI/CD environments, verify the following:
- ☐ Secure development policy explicitly addresses CI/CD pipelines and automated processes
- ☐ Security requirements are defined before development and traceable to pipeline verification
- ☐ Change control procedures reference the CI/CD pipeline as the enforcement mechanism
- ☐ Pipeline includes mandatory approval gates before production deployment
- ☐ All pipeline executions produce immutable audit trails (who, what, when, outcome)
- ☐ Security testing stages are mandatory and cannot be bypassed without documented justification
- ☐ Security test failures block deployment progression
- ☐ Acceptance criteria are defined, approved, and enforced by the pipeline
- ☐ Build environments are isolated, hardened, and access-controlled
- ☐ Outsourced development is subject to the same pipeline controls as internal development
- ☐ Third-party package modifications are formally approved and integrity-verified
- ☐ Platform changes trigger regression testing
- ☐ Emergency change procedures exist with retrospective review requirements
- ☐ Evidence is retained per the organisation’s retention policy
Further Reading
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- Continuous Compliance via CI/CD
- Audit Readiness Checklist
- Core CI/CD Security Controls
New to CI/CD auditing? Start with our Auditor’s Guide.
