1. Purpose
The Go-Live Security Approval Form is used to confirm that required security activities have been completed before a new application, system, major change, or project is moved into production.
The approval confirms that:
- Security requirements have been addressed.
- Project security risks have been assessed.
- The architecture has been reviewed.
- Required security controls have been implemented.
- Security testing has been completed.
- Significant security findings have been remediated or formally accepted.
- Residual risks are understood.
- Required security evidence is available.
- Appropriate owners have approved the production release.
This form should be completed before production deployment unless an approved exception applies.
2. Go-Live Information
| Field | Details |
|---|---|
| Project Name | [Project Name] |
| Project ID | [Project ID] |
| Application/System | [Name] |
| Release Version | [Version] |
| Release Date | [Date] |
| Business Owner | [Name] |
| Project Manager | [Name] |
| Technical Owner | [Name] |
| Security Owner | [Name] |
| Change/Release ID | [ID] |
| Production Environment | [Environment] |
| Planned Go-Live Time | [Date/Time] |
| Security Review Date | [Date] |
| Approval Status | [Approved / Conditional / Not Approved] |
3. Go-Live Scope
What is being released?
[Describe application, feature, infrastructure, service, or major change.]
Business Purpose
[Describe why the release is required.]
Systems/Components Affected
- [Application]
- [Database]
- [API]
- [Cloud infrastructure]
- [Third-party services]
- [Other]
Data Processed
- [Customer data]
- [Personal data]
- [Financial data]
- [Confidential business information]
- [Other]
Data Classification
[Public / Internal / Confidential / Restricted]
4. Security Readiness Summary
| Security Area | Required | Completed | Evidence | Status |
|---|---|---|---|---|
| Security Requirements | ☐ | ☐ | [Link/Ref] | |
| Project Risk Assessment | ☐ | ☐ | [Link/Ref] | |
| Security Architecture Review | ☐ | ☐ | [Link/Ref] | |
| Threat Assessment | ☐ | ☐ | [Link/Ref] | |
| Secure Development Review | ☐ | ☐ | [Link/Ref] | |
| Security Testing | ☐ | ☐ | [Link/Ref] | |
| Vulnerability Assessment | ☐ | ☐ | [Link/Ref] | |
| VAPT/Penetration Testing | ☐ | ☐ | [Link/Ref] | |
| Access Control Review | ☐ | ☐ | [Link/Ref] | |
| Cloud Security Review | ☐ | ☐ | [Link/Ref] | |
| Backup/Recovery | ☐ | ☐ | [Link/Ref] | |
| Logging/Monitoring | ☐ | ☐ | [Link/Ref] | |
| Incident Readiness | ☐ | ☐ | [Link/Ref] | |
| Security Exceptions | ☐ | ☐ | [Link/Ref] |
5. Security Requirements Verification
Confirm that applicable security requirements have been implemented and verified.
| Requirement ID | Requirement | Implementation | Verification | Result |
|---|---|---|---|---|
| SR-001 | Privileged users require MFA | Implemented | IAM review | Pass |
| SR-002 | Customer data encrypted | Implemented | Configuration review | Pass |
| SR-003 | Production access restricted | Implemented | Access testing | Pass |
| SR-004 | Security logging enabled | Implemented | Log verification | Pass |
Result
- ☐ All applicable requirements completed
- ☐ Outstanding requirements documented and approved
- ☐ Requirements requiring post-go-live completion have owners and deadlines
6. Project Risk Assessment
Confirm that project risks have been reviewed.
- ☐ Project Risk Assessment completed
- ☐ Security risks identified
- ☐ Initial risks assessed
- ☐ Risk treatments completed where required
- ☐ Residual risks assessed
- ☐ Risk owners identified
- ☐ Risk acceptance completed where required
Outstanding Risks
| Risk ID | Risk | Residual Level | Owner | Treatment/Acceptance | Status |
|---|---|---|---|---|---|
| PR-001 | [Risk] | [Level] | [Owner] | [Action] | Open |
7. Security Architecture Approval
Confirm that the final implementation is consistent with the reviewed architecture.
- ☐ Security Architecture Review completed
- ☐ Architecture changes reviewed
- ☐ Data flows confirmed
- ☐ Trust boundaries reviewed
- ☐ Network security reviewed
- ☐ IAM reviewed
- ☐ Cloud architecture reviewed
- ☐ Third-party integrations reviewed
- ☐ Architecture findings addressed
- ☐ Approved exceptions documented
Architecture Status
☐ Approved
☐ Approved with Conditions
☐ Rework Required
8. Secure Development Verification
- ☐ Secure development checklist completed
- ☐ Source repository access reviewed
- ☐ Code review completed
- ☐ Security-sensitive code reviewed
- ☐ Secrets scanning completed
- ☐ Dependency scanning completed
- ☐ Secure coding requirements addressed
- ☐ CI/CD security reviewed
- ☐ Infrastructure-as-Code reviewed where applicable
- ☐ Container security reviewed where applicable
9. Security Testing Verification
Confirm applicable security testing has been completed.
| Test | Applicable | Completed | Result | Evidence |
|---|---|---|---|---|
| SAST | ☐ | ☐ | Pass/Fail | [Ref] |
| DAST | ☐ | ☐ | Pass/Fail | [Ref] |
| SCA | ☐ | ☐ | Pass/Fail | [Ref] |
| Secret Scan | ☐ | ☐ | Pass/Fail | [Ref] |
| API Testing | ☐ | ☐ | Pass/Fail | [Ref] |
| Vulnerability Assessment | ☐ | ☐ | Pass/Fail | [Ref] |
| VAPT | ☐ | ☐ | Pass/Fail | [Ref] |
| Penetration Testing | ☐ | ☐ | Pass/Fail | [Ref] |
| Cloud Security Testing | ☐ | ☐ | Pass/Fail | [Ref] |
| Configuration Testing | ☐ | ☐ | Pass/Fail | [Ref] |
Not every test is applicable to every project. The reason for any significant exclusion should be documented where appropriate.
10. Security Findings
Review all outstanding security findings.
| Finding ID | Finding | Severity | Risk | Remediation | Status | Approval |
|---|---|---|---|---|---|---|
| SEC-001 | [Finding] | High | High | [Action] | Closed | — |
| SEC-002 | [Finding] | Medium | Medium | [Action] | Open | [Name] |
Critical/High Findings
- ☐ No unresolved Critical findings
- ☐ No unresolved High findings
- ☐ Outstanding findings have approved risk treatment/acceptance
The organization’s approved risk methodology and release criteria should determine whether an unresolved finding prevents go-live.
11. Retesting
For findings requiring remediation:
- ☐ Remediation completed
- ☐ Original test repeated
- ☐ Fix verified
- ☐ No regression identified
- ☐ Evidence retained
| Finding | Original Result | Fix | Retest Result | Date | Tester |
|---|---|---|---|---|---|
| SEC-001 | Fail | [Fix] | Pass | [Date] | [Name] |
12. Access Control Readiness
- ☐ User roles defined
- ☐ Access approvals completed
- ☐ Least privilege applied
- ☐ Privileged access reviewed
- ☐ MFA implemented where required
- ☐ Production access restricted
- ☐ Service accounts reviewed
- ☐ API credentials protected
- ☐ Third-party access reviewed
- ☐ Temporary access controlled
- ☐ Access logging enabled
13. Cloud and Infrastructure Readiness
For cloud environments:
- ☐ IAM configured
- ☐ MFA configured where required
- ☐ Network segmentation implemented
- ☐ Security Groups/firewalls reviewed
- ☐ Public exposure reviewed
- ☐ Storage permissions reviewed
- ☐ Database access restricted
- ☐ Encryption enabled where required
- ☐ Secrets protected
- ☐ Cloud logging enabled
- ☐ Monitoring enabled
- ☐ Security alerts configured
- ☐ Backup configured
- ☐ Security findings addressed
AWS Example
Confirm applicable controls such as:
- AWS IAM
- VPC
- Security Groups
- RDS
- S3
- KMS
- Secrets Manager
- CloudTrail
- CloudWatch
- WAF
- Backup
Only applicable services should be included.
14. Data Protection Readiness
- ☐ Data classification completed
- ☐ Sensitive data identified
- ☐ Encryption verified
- ☐ Data access restricted
- ☐ Data retention considered
- ☐ Data deletion requirements considered
- ☐ Privacy requirements addressed
- ☐ Data transfers reviewed
- ☐ Backup copies considered
- ☐ Production/test data separation confirmed
15. Logging and Monitoring Readiness
Confirm that security-relevant events can be detected and investigated.
- ☐ Authentication events logged
- ☐ Failed authentication logged
- ☐ Privileged actions logged
- ☐ Administrative changes logged
- ☐ Security events logged
- ☐ Application logs enabled
- ☐ Cloud logs enabled
- ☐ Monitoring operational
- ☐ Security alerts configured
- ☐ Alert ownership assigned
- ☐ Log retention defined
- ☐ Logs protected from unauthorized modification
16. Backup and Recovery Readiness
- ☐ Backup configured
- ☐ Backup frequency verified
- ☐ Backup access restricted
- ☐ Backup encryption verified
- ☐ Recovery procedure available
- ☐ Restoration tested where required
- ☐ RTO considered
- ☐ RPO considered
- ☐ Disaster recovery requirements addressed
- ☐ Recovery ownership defined
17. Incident Response Readiness
Before go-live:
- ☐ Application/system included in incident response process
- ☐ Security contacts identified
- ☐ Escalation contacts identified
- ☐ Monitoring alerts connected to response process
- ☐ Incident reporting mechanism available
- ☐ Relevant logs available for investigation
- ☐ Evidence preservation considered
- ☐ Customer communication requirements considered
- ☐ Regulatory notification requirements considered where applicable
- ☐ Recovery procedure available
18. Change and Deployment Readiness
- ☐ Change request approved
- ☐ Deployment plan approved
- ☐ Deployment owner identified
- ☐ Deployment window defined
- ☐ Rollback plan available
- ☐ Backup completed where required
- ☐ Production access controlled
- ☐ Deployment credentials protected
- ☐ Change record maintained
- ☐ Post-deployment validation planned
19. Third-Party Readiness
Where third parties are involved:
- ☐ Supplier security assessment completed where required
- ☐ Security requirements included in agreement where applicable
- ☐ Data shared with supplier identified
- ☐ Supplier access reviewed
- ☐ API security reviewed
- ☐ Incident notification requirements reviewed
- ☐ Supplier availability requirements considered
- ☐ Relevant supplier risks assessed
20. Go-Live Conditions
Document anything that must be completed before or immediately after go-live.
| Condition ID | Condition | Owner | Due Date | Before/After Go-Live | Status |
|---|---|---|---|---|---|
| GL-001 | [Condition] | [Owner] | [Date] | Before | Open |
| GL-002 | [Condition] | [Owner] | [Date] | After | Open |
Any post-go-live action should have:
- Named owner
- Target date
- Risk assessment
- Appropriate approval
- Tracking mechanism
21. Security Exceptions
| Exception ID | Requirement | Reason | Risk | Compensating Control | Approver | Expiry |
|---|---|---|---|---|---|---|
| EX-001 | [Requirement] | [Reason] | [Risk] | [Control] | [Name] | [Date] |
Exceptions should not be used to bypass security requirements without appropriate risk assessment and authorization.
22. Final Security Readiness Checklist
Requirements
- ☐ Security requirements completed
- ☐ Outstanding requirements documented
Risk
- ☐ Project risks assessed
- ☐ Residual risks assessed
- ☐ Risk acceptance completed where required
Architecture
- ☐ Security Architecture Review completed
- ☐ Final architecture reviewed
Development
- ☐ Secure Development Checklist completed
- ☐ Code review completed
- ☐ Dependencies reviewed
- ☐ Secrets reviewed
Testing
- ☐ Applicable security testing completed
- ☐ Vulnerability assessment completed
- ☐ VAPT/penetration testing completed where required
- ☐ Critical/high findings addressed or formally accepted
- ☐ Retesting completed
Infrastructure
- ☐ IAM reviewed
- ☐ Network security reviewed
- ☐ Encryption verified
- ☐ Cloud security reviewed
- ☐ Logging/monitoring enabled
- ☐ Backup/recovery verified
Operations
- ☐ Incident response ready
- ☐ Monitoring operational
- ☐ Support ownership defined
- ☐ Deployment and rollback plans ready
Documentation
- ☐ Evidence retained
- ☐ Exceptions documented
- ☐ Outstanding actions tracked
- ☐ Required approvals obtained
23. Go-Live Security Decision
Based on the completed security assessment:
☐ Approved for Go-Live
Applicable security requirements and risk treatment have been completed or appropriately accepted.
☐ Approved with Conditions
The system may proceed subject to the documented conditions and deadlines.
☐ Not Approved
Security issues require further treatment before production deployment.
Decision Comments
[Enter decision rationale.]
24. Approval
Business Owner
Name: ______________________
Role: ______________________
Approval: ______________________
Date: ______________________
Technical Owner
Name: ______________________
Role: ______________________
Approval: ______________________
Date: ______________________
Security Owner / Security Reviewer
Name: ______________________
Role: ______________________
Approval: ______________________
Date: ______________________
Risk Owner
Name: ______________________
Role: ______________________
Approval: ______________________
Date: ______________________
Final Release Approver
Name: ______________________
Role: ______________________
Approval: ______________________
Date: ______________________
25. Post-Go-Live Verification
Within the organization’s defined post-deployment review period:
- ☐ Application functioning as expected
- ☐ Security controls operational
- ☐ Authentication verified
- ☐ Authorization verified
- ☐ Logging verified
- ☐ Monitoring verified
- ☐ Alerts functioning
- ☐ No unexpected public exposure
- ☐ Backup functioning
- ☐ No significant security incident identified
- ☐ Outstanding go-live conditions reviewed
- ☐ Residual risks reviewed
Post-Go-Live Review
Reviewer: ______________________
Date: ______________________
Result: ______________________
Comments: ______________________
26. Audit Evidence
The completed Go-Live Security Approval Form can serve as a central reference linking:
- Project Security Requirements
- Project Risk Assessment
- Security Architecture Review
- Secure Development Checklist
- Security Testing Checklist
- Vulnerability Assessment
- VAPT/Penetration Testing
- Security findings
- Risk acceptance
- Change approval
- Deployment evidence
- Cloud configuration
- Access control evidence
- Backup/recovery evidence
- Logging/monitoring evidence
The auditor should be able to trace:
Requirement → Risk → Architecture → Development → Testing → Finding → Remediation → Retest → Residual Risk → Approval → Go-Live → Monitoring
27. Startup-Friendly Go-Live Process
For a typical SaaS startup, the process can be kept simple:
Security Requirements
↓
Project Risk Assessment
↓
Security Architecture Review
↓
Secure Development
↓
Security Testing
↓
Fix Critical/High Findings
↓
Retest
↓
Review Residual Risk
↓
Security Approval
↓
Production Deployment
↓
Post-Go-Live Verification
↓
Continuous Monitoring
The form should be proportionate to the project’s risk. A small low-risk application change should not require the same approval process as a new internet-facing platform processing sensitive customer information.
28. Relationship With Other ISMS Documents
The Go-Live Security Approval Form is the final control point in the project security lifecycle and connects with:
- Project Security Requirements Template
- Project Risk Assessment
- Security Architecture Review
- Secure Development Checklist
- Security Testing Checklist
- Vulnerability Management Procedure
- Threat Intelligence Procedure
- Access Control Policy
- Change Management Procedure
- Incident Response Plan
- Backup and Recovery Procedure
- Supplier Security Assessment
- Risk Register
- Statement of Applicability
Overall Lifecycle
Requirements → Risk → Architecture → Development → Testing → Remediation → Retesting → Approval → Go-Live → Monitoring → Improvement
29. Final Principle
Go-live approval should not simply mean:
“The application is ready to deploy.”
It should demonstrate:
“The security requirements have been addressed, project risks have been assessed, security controls have been verified, significant findings have been treated or accepted, and the appropriate owners have authorized production deployment.”
Assess → Build → Test → Remediate → Verify → Approve → Deploy → Monitor → Improve