Production Deployment Procedure

1. Purpose

The Production Deployment Procedure defines how application code, infrastructure, configuration, database changes, security changes, and other technology changes are safely deployed into production.

The objective is to ensure that production deployments are:

Authorized
Tested
Secure
Traceable
Controlled
Reversible where practical
Monitored
Properly documented
Supported by appropriate evidence

Core Principle

Plan → Review → Test → Approve → Deploy → Verify → Monitor → Record

2. Scope

This procedure applies to deployments involving:

Production applications
Application code
APIs
Databases
Infrastructure
Cloud resources
Infrastructure-as-Code
Configuration
Security controls
CI/CD pipelines
Operating systems
Containers
Kubernetes environments
Serverless applications
Third-party integrations
Production dependencies

It applies to:

Developers
DevOps engineers
Cloud administrators
System administrators
Application owners
Security personnel
Release managers
Approved third parties

3. Deployment Information

Field	Details
Procedure ID
Procedure Owner
Application/System
Technical Owner
Deployment Owner
Security Owner
Version
Effective Date
Review Date
Classification
Approved By

4. Deployment Objectives

The production deployment process should ensure:

☐ Change is authorized
☐ Code/version is identified
☐ Security impact is assessed
☐ Testing is completed
☐ Required approvals exist
☐ Dependencies are understood
☐ Backup/recovery is considered
☐ Rollback plan exists where appropriate
☐ Deployment is performed by authorized personnel
☐ Production activity is traceable
☐ Deployment is monitored
☐ Post-deployment verification is completed
☐ Evidence is retained

5. Deployment Types

Classify the deployment.

☐ Standard Deployment
☐ Normal Deployment
☐ Major Release
☐ Minor Release
☐ Hotfix
☐ Emergency Deployment
☐ Security Patch
☐ Infrastructure Deployment
☐ Database Deployment
☐ Configuration Deployment
☐ Rollback

6. Roles and Responsibilities

Role	Responsibility
Developer	Develops and prepares release
Code Reviewer	Reviews code/change
QA/Test Owner	Performs testing
Deployment Owner	Coordinates deployment
DevOps/Cloud Engineer	Performs deployment
Security	Reviews security impact where required
Application Owner	Approves release
Business Owner	Confirms business impact where required
Incident Manager	Coordinates emergency deployment when applicable

7. Deployment Prerequisites

Before production deployment:

☐ Change request exists
☐ Deployment scope defined
☐ Release version identified
☐ Code review completed
☐ Required tests completed
☐ Security checks completed where required
☐ Required approvals obtained
☐ Dependencies identified
☐ Backup/recovery considered
☐ Rollback plan prepared
☐ Deployment window defined
☐ Monitoring available
☐ Responsible personnel available

8. Source Code Management

Production code should originate from an approved source-code repository.

Controls should include:

☐ Version control
☐ Individual user accounts
☐ MFA
☐ Branch protection where appropriate
☐ Code review
☐ Commit traceability
☐ Release/tag identification
☐ Restricted production deployment permissions

9. Code Review

Before production deployment, code should be reviewed according to the organization’s development process.

Review may consider:

Functionality
Security
Quality
Dependencies
Error handling
Authentication
Authorization
Logging
Sensitive information
Secrets
Performance
Data handling

Review Evidence

10. Security Testing

Where applicable, perform security checks before deployment.

☐ SAST
☐ DAST
☐ Dependency scanning
☐ Container scanning
☐ Secret scanning
☐ Vulnerability scanning
☐ Configuration review
☐ Security testing
☐ Penetration testing for significant changes

The level of testing should be proportionate to the risk and nature of the change.

11. Testing Requirements

Before production deployment, complete appropriate testing.

Test	Required?	Result	Evidence
Unit testing
Integration testing
Functional testing
Regression testing
Security testing
Performance testing
User acceptance testing

12. Test Environment

Where practical, test the release in a non-production environment.

Examples:

Development
QA
Staging
Pre-production

The environment should be sufficiently representative of production for the intended test.

13. Production Data Protection

Production information must be protected during deployment.

Avoid unnecessary copying of:

Customer data
Personal data
Credentials
Production database contents
Confidential information

If production data is required for testing or troubleshooting, apply appropriate:

Authorization
Data minimization
Masking
Access restrictions
Logging
Retention
Secure deletion

14. Release Identification

Every production release should be uniquely identifiable.

Record:

Field	Details
Release ID
Version
Commit/Tag
Build ID
Deployment Date
Deployment Owner
Environment	Production
Change ID

15. Deployment Package

Before deployment, verify:

☐ Correct version selected
☐ Build completed successfully
☐ Dependencies identified
☐ Security scans completed
☐ Configuration identified
☐ Database migrations identified
☐ Infrastructure changes identified
☐ Release notes prepared
☐ Deployment instructions available

16. Configuration Management

Production configuration must be controlled.

Examples:

Environment variables
Feature flags
API endpoints
Database settings
Security settings
Cloud configuration
Application configuration

Sensitive configuration must be stored using approved secrets-management mechanisms.

Do not store passwords, API keys, private keys, or other secrets in source code or ordinary deployment documentation.

17. Secrets Management

Deployment processes must protect:

API keys
Database credentials
Cloud credentials
SSH keys
Tokens
Certificates
Encryption keys

☐ Secure secret store used
☐ Access restricted
☐ Secrets not committed to source code
☐ Rotation requirements defined
☐ Deployment access controlled

18. Deployment Approval

Production deployment requires appropriate approval based on risk.

Possible approval roles include:

Application Owner
Engineering Manager
Change Manager
Security
Business Owner

Approval Record

Approver	Role	Decision	Date
		Approved / Rejected

19. Deployment Window

Define the planned deployment period.

Start: __________________

End: __________________

Time Zone: __________________

Consider:

Customer impact
Business hours
Support availability
Monitoring availability
Dependency availability
Rollback time
Maintenance requirements

20. Deployment Communication

Where appropriate, notify affected stakeholders.

☐ Engineering
☐ IT Operations
☐ Security
☐ Customer Support
☐ Business Owner
☐ Management
☐ Customers
☐ Supplier

Communication

21. Backup and Recovery

Before high-risk deployments:

☐ Backup completed
☐ Backup status verified
☐ Recovery method available
☐ Recovery owner identified
☐ Recovery time considered
☐ Rollback plan reviewed

Database changes require particular attention to backup and recovery.

22. Rollback Plan

A rollback or recovery approach should be defined where practical.

Rollback Trigger

Rollback Steps

Step	Action	Owner
1
2
3

Rollback Verification

23. Production Deployment Steps

Step 1 — Confirm Release

Verify:

☐ Correct release
☐ Correct environment
☐ Correct deployment target
☐ Required approvals

Step 2 — Confirm Readiness

Verify:

☐ Backup
☐ Monitoring
☐ Support availability
☐ Rollback capability
☐ Dependencies

Step 3 — Deploy

Perform the approved deployment steps.

Step 4 — Monitor

Monitor:

Application health
Error rates
Infrastructure
Security alerts
Database health
Network
Customer-facing services

Step 5 — Verify

Confirm the release operates as expected.

24. Deployment Execution Record

Time	Activity	Person	Result

25. Post-Deployment Verification

Verify:

☐ Application starts successfully
☐ Critical functions work
☐ APIs operate correctly
☐ Database connectivity works
☐ Authentication works
☐ Authorization works
☐ Logging works
☐ Monitoring works
☐ Security controls remain active
☐ Integrations work
☐ Performance acceptable
☐ No unexpected security issue identified

Verification Result

26. Smoke Testing

Immediately after deployment, perform appropriate smoke tests.

Examples:

Application login
Critical workflow
API health check
Database connection
Payment transaction test where applicable
Customer-facing functionality
Monitoring alert test

Smoke Test Result

Result: ☐ Passed ☐ Failed ☐ Partially Passed

Tester: __________________

Date: __________________

27. Database Changes

Database deployments require additional controls.

Before deployment:

☐ Schema change identified
☐ Migration tested
☐ Backup completed
☐ Rollback/recovery considered
☐ Data impact assessed
☐ Performance impact assessed

After deployment:

☐ Migration completed
☐ Database health verified
☐ Application connectivity verified
☐ Data integrity verified where appropriate

28. Infrastructure Deployment

Infrastructure changes may include:

AWS resources
Terraform
CloudFormation
Kubernetes
Network configuration
IAM
Security groups
Load balancers
Storage
Databases

Infrastructure changes should be:

☐ Version controlled
☐ Reviewed
☐ Tested
☐ Approved
☐ Traceable
☐ Monitored

29. Infrastructure-as-Code

Where Infrastructure-as-Code is used:

☐ Code stored in version control
☐ Peer review performed
☐ Security checks performed
☐ Plan reviewed
☐ Approval obtained
☐ Deployment performed through controlled mechanism
☐ Result verified

30. CI/CD Deployment

Where CI/CD is used:

Developer commits code.
Automated checks execute.
Build is created.
Security scans execute where configured.
Tests execute.
Release candidate is created.
Required approval is obtained.
Production deployment executes.
Monitoring begins.
Deployment result is recorded.

CI/CD Evidence

31. Production Access

Production deployment access must be restricted.

☐ Authorized personnel
☐ Named accounts
☐ MFA
☐ Least privilege
☐ Deployment permissions restricted
☐ Privileged activity logged
☐ Access periodically reviewed

Developers should not automatically receive unrestricted production access merely because they develop the application.

32. Deployment Monitoring

After deployment, monitor according to risk.

Consider:

☐ Application errors
☐ HTTP error rates
☐ CPU/memory
☐ Database performance
☐ Network health
☐ Security alerts
☐ Authentication failures
☐ Customer complaints
☐ Service availability
☐ Business transaction failures

33. Failed Deployment

If a deployment fails:

Stop further deployment.
Assess impact.
Stabilize the service.
Activate rollback/recovery where required.
Notify relevant stakeholders.
Investigate the cause.
Preserve evidence.
Record the failure.
Create corrective action where required.
Reassess before attempting deployment again.

34. Rollback

Rollback should be initiated when:

Critical functionality fails
Security controls are compromised
Data integrity is at risk
Service availability is materially affected
Performance is unacceptable
Approved rollback criteria are met

Rollback Record

Item	Details
Reason
Time
Responsible Person
Rollback Version
Result
Verification

35. Emergency Deployment

Emergency deployment may be required for:

Critical security vulnerability
Active security incident
Major service outage
Critical production defect
Significant customer impact

Process:

Assess → Authorize → Deploy → Monitor → Stabilize → Verify → Document → Review

Emergency deployment should not become a routine method for bypassing normal change controls.

36. Hotfix

A hotfix is a targeted production change intended to address an urgent issue.

Before implementation where practical:

☐ Issue confirmed
☐ Risk assessed
☐ Scope minimized
☐ Testing performed
☐ Approval obtained
☐ Rollback considered

After implementation:

☐ Smoke test
☐ Monitoring
☐ Verification
☐ Documentation
☐ Follow-up release if required

37. Security Incident During Deployment

If a security incident occurs during deployment:

Stop → Contain → Escalate → Investigate → Recover → Record

Activate the organization’s Incident Response Procedure where required.

Preserve relevant:

Deployment logs
CI/CD logs
Application logs
Cloud logs
Access logs
Change records
Error messages

38. Post-Deployment Review

For significant deployments, review:

Expected vs. actual outcome
Incidents
Performance
Security issues
Customer impact
Rollback
Monitoring
Process effectiveness
Lessons learned

Review

39. Deployment Closure

A deployment can be closed when:

☐ Deployment completed
☐ Smoke testing completed
☐ Production verified
☐ Monitoring completed
☐ Issues resolved or tracked
☐ Evidence retained
☐ Change record updated
☐ Stakeholders informed where required

Closure Result

☐ Successful
☐ Successful with Issues
☐ Rolled Back
☐ Failed

40. Deployment Evidence

Maintain appropriate evidence such as:

☐ Change request
☐ Approval
☐ Release ID
☐ Git commit/tag
☐ Code review
☐ Test results
☐ Security scan results
☐ CI/CD logs
☐ Deployment logs
☐ Infrastructure change record
☐ Database migration evidence
☐ Backup evidence
☐ Rollback evidence
☐ Smoke-test results
☐ Monitoring results
☐ Post-deployment review

Do not store passwords, API keys, private keys, or other secrets in deployment evidence.

41. Deployment Metrics

Possible metrics:

Metric	Target	Frequency
Deployment success rate
Failed deployments
Rollback rate
Emergency deployments
Deployment-related incidents
Mean deployment duration
Changes without approval
Post-deployment defects

Metrics should be used to improve deployment quality and operational risk management.

42. Deployment Exceptions

Exceptions to this procedure should be:

☐ Documented
☐ Justified
☐ Risk assessed
☐ Approved
☐ Time-bound where appropriate
☐ Reviewed
☐ Closed

43. AWS SaaS Startup Example

Environment

A SaaS startup operates:

AWS
GitHub
CI/CD
RDS
S3
CloudFront
Route 53
Application servers/containers
Monitoring

Scenario

A developer has completed a new application release.

Deployment Flow

1. Code

Developer creates a pull request.

2. Review

Another authorized developer reviews the code.

3. Automated Checks

CI pipeline performs:

Unit tests
Integration tests
Dependency scan
Secret scan
Build

4. Staging

Application is deployed to staging.

5. Testing

QA performs functional and regression testing.

6. Approval

Application owner approves production deployment.

7. Change Record

Deployment is linked to the approved change ticket.

8. Production Deployment

CI/CD deploys the approved release.

9. Monitoring

Team monitors:

Application errors
AWS infrastructure
Database
Security alerts
Customer-facing functionality

10. Verification

Smoke tests confirm:

Login
API
Database
Critical application workflow

11. Closure

Deployment evidence is attached to the change record.

Audit Trail

Git Commit → Code Review → CI Tests → Security Scan → Staging → Approval → Change Ticket → Production Deployment → Monitoring → Smoke Test → Closure

44. Startup-Friendly Deployment Model

Normal Deployment

Code → Review → Test → Approve → Deploy → Verify

High-Risk Deployment

Code → Review → Security Test → Risk Assessment → Approval → Backup → Deploy → Monitor → Verify

Emergency Deployment

Assess → Approve → Deploy → Monitor → Stabilize → Document → Review

Rollback

Detect Failure → Stop → Rollback → Verify → Investigate → Correct

This provides control without requiring a complex approval process for every small release.

45. Common Mistakes

Avoid:

Deploying directly to production without review.
Allowing developers to bypass CI/CD without justification.
Deploying untested code.
Failing to identify the exact production version.
Not linking deployment to a change record.
Deploying without rollback planning for high-risk changes.
Failing to monitor after deployment.
Ignoring database migration risks.
Storing production credentials in deployment scripts.
Giving all developers unrestricted production deployment permissions.
Treating successful deployment as proof that the application is functioning correctly.
Not performing post-deployment verification.
Using emergency deployments to bypass normal controls routinely.
Failing to preserve deployment evidence.

46. Relationship With Other ISMS Documents

Document	Relationship
Change Management Procedure	Controls the underlying change
Secure Development Procedure	Controls software development
Code Review Procedure	Controls code review
Vulnerability Management Procedure	Manages vulnerabilities
Access Management Procedure	Controls deployment access
Cloud Security Policy	Governs cloud deployment
Configuration Management Procedure	Controls configurations
Backup & Restore Procedure	Supports recovery
Incident Response Procedure	Handles deployment-related incidents
Business Continuity Plan	Supports major service disruption
Risk Assessment	Assesses deployment risk
Security Testing Procedure	Supports security validation
Corrective Action Tracker	Tracks deployment weaknesses

47. ISO/IEC 27001 Connection

Production deployment supports the organization’s risk-based management of information systems by ensuring that changes are appropriately authorized, tested, protected, implemented, and verified.

The exact deployment controls should be determined based on:

ISMS scope
Risk assessment
Risk treatment
Statement of Applicability
Applicable controls
Technology architecture
Business requirements
Legal/regulatory requirements
Customer requirements
Contractual requirements

This Production Deployment Procedure is not itself a universally prescribed ISO/IEC 27001 document. The organization should maintain the documented information and operational evidence necessary to demonstrate that production changes are appropriately controlled.

48. Audit Evidence Checklist

An auditor should be able to trace:

☐ Approved change
☐ Release/version
☐ Code repository
☐ Code review
☐ Test results
☐ Security testing
☐ Deployment approval
☐ CI/CD evidence
☐ Deployment logs
☐ Production access
☐ Backup/recovery
☐ Rollback plan
☐ Post-deployment verification
☐ Monitoring evidence
☐ Incident records
☐ Deployment closure
☐ Lessons learned

49. Final Production Deployment Audit Trail

For every significant production deployment, the organization should be able to demonstrate:

What was deployed?

Which version was deployed?

Who developed it?

Who reviewed it?

What testing was performed?

What security checks were performed?

Who approved production deployment?

Which change record authorized it?

Who performed the deployment?

What happened during deployment?

Was production successfully verified?

Was the system monitored after deployment?

What evidence proves the deployment was successful?

Final Principle

A production deployment is not complete when code reaches the production server. It is complete when the authorized release has been deployed, verified, monitored, and supported by a traceable audit trail.