CI/CD Pipelines in Regulated Environments
Use this cheat sheet during audit day to answer common CI/CD questions clearly, consistently, and with evidence.
Short answers. No speculation. Always follow up with proof.
1. Scope & Governance
Q: Are CI/CD pipelines in scope for compliance ?
Answer
Yes. CI/CD pipelines are treated as regulated ICT systems because they directly impact production systems.
Evidence to show
- ICT system inventory
- Risk assessment including CI/CD
Q: Who owns CI/CD security and governance ?
Answer
CI/CD governance is jointly owned by Platform Engineering and Security, with defined accountability.
Evidence
- RACI or ownership document
- Governance policy reference
2. Access Control
Q: Who can modify CI/CD pipelines ?
Answer
Only authorized administrators with RBAC and MFA can modify pipeline configurations.
Evidence
- CI/CD RBAC configuration
- IAM policies
- MFA enforcement screen/logs
Q: Do pipelines use shared credentials ?
Answer
No. Each pipeline uses dedicated service accounts with least privilege.
Evidence
- Service account list
- Permission scopes
3. Segregation of Duties
Q: Can developers deploy directly to production ?
Answer
No. Production deployments require independent approval enforced by the pipeline.
Evidence
- Approval rules
- Deployment workflow definition
Q: Can someone approve their own changes ?
Answer
No. Self-approval is technically prevented.
Evidence
- Pull request rules
- Approval history example
4. Change Management
Q: How do you ensure all production changes go through CI/CD ?
Answer
Direct production access is restricted. All deployments are executed via CI/CD pipelines.
Evidence
- Deployment logs
- Infrastructure access restrictions
Q: Can you trace a production release back to source code ?
Answer
Yes. We maintain full traceability from commit to deployment.
Evidence
- Commit ID
- Pipeline run ID
- Artifact metadata
5. Security Controls
Q: Are security scans mandatory ?
Answer
Yes. Security scans are enforced and block deployment on failure.
Evidence
- Pipeline definition
- Failed build example
Q: How are security exceptions handled ?
Answer
Exceptions require formal approval and are logged.
Evidence
- Exception records
- Approval logs
6. Logging & Monitoring
Q: Are CI/CD activities logged ?
Answer
Yes. All pipeline executions and changes are logged centrally.
Evidence
- Central log dashboard
- Sample pipeline logs
Q: How long are CI/CD logs retained ?
Answer
Logs are retained in accordance with regulatory requirements.
Evidence
- Retention policy
- SIEM configuration
7. Incident & Resilience
Q: What happens if a CI/CD credential is compromised ?
Answer
Credentials can be revoked immediately and pipelines disabled.
Evidence
- IAM revocation process
- Incident playbook excerpt
Q: Do you test rollback procedures ?
Answer
Yes. Rollback and recovery procedures are tested regularly.
Evidence
- Test records
- Deployment history
8. Evidence Quality
Q: How do you provide audit evidence ?
Answer
Evidence is system-generated, timestamped, and reproducible.
Evidence
- Logs
- Pipeline metadata
- Audit trail samples
Q: Can you reproduce evidence on demand ?
Answer
Yes. Evidence can be retrieved directly from CI/CD and logging systems.
Evidence
- Live query or prepared report
9. Handling Difficult Questions
Q: “Why don’t you do X ?“
Safe answer
This control is addressed through alternative mechanisms aligned with our risk assessment.
👉 Then show what you do, not what you don’t.
Q: “Isn’t this non-compliant ?“
Safe answer
Based on our interpretation and controls in place, this requirement is addressed. We are open to further clarification.
⚠️ Never argue regulation interpretation emotionally.
10. Final Golden Rules (Print This)
- Do not speculate
- Do not over-explain
- Show evidence, then stop
- One voice at a time
- CI/CD is a regulated system
Related Resources
- Audit Day Playbook
- Before the Auditor Arrives
- CI/CD Audit Red Flags
- How Auditors Actually Review CI/CD
- DORA Article 21 Auditor Checklist
📌 USAGE NOTES (important)
- Keep this open during audit calls
- Share only with audit-facing team
- Do not improvise outside this scope
- Update it after each audit
