Overview
The Architecture Review Process is a formal evaluation of proposed system architecture changes to ensure they meet security, availability, and change management requirements before implementation. It supports SOC 2 CC8.1 by ensuring significant changes are reviewed, approved, and documented prior to deployment.
Step-by-Step Process
Initiate architecture review request
The Engineering Lead submits an architecture review request when a major system change is proposed. The request must summarize the change scope, affected systems, and target deployment date. The output is a logged review request with a unique identifier.
Role: Engineering Lead
Document proposed architecture
The assigned engineer creates or updates architecture diagrams showing current and proposed states. Diagrams must clearly identify data flows, external dependencies, and security boundaries. The output is a dated architecture diagram draft.
Role: Senior Engineer
Assess security and control impacts
Security or platform stakeholders review the proposed architecture for impacts to SOC 2 controls, including access control, logging, and availability. Identified risks and required mitigations are documented in the review record. The output is a completed risk and impact assessment.
Role: Security Engineer
Review against change criteria
The Engineering Lead verifies the change meets CC8.1 requirements by confirming authorization, testing expectations, and rollback considerations. Any gaps are documented and returned for remediation. The output is a review checklist marked complete or pending.
Role: Engineering Lead
Obtain formal approval
Designated approvers review the final architecture and documented risks and either approve or reject the change. Approval must be recorded with name, role, and date. The output is an approved architecture review record.
Role: Engineering Manager
Store approved artifacts
All final diagrams, assessments, and approvals are stored in the designated documentation repository. Files must be versioned and access-controlled. The output is a centralized, auditable record set.
Role: Engineering Lead
Link review to change implementation
The approved architecture review is linked to the corresponding change ticket or deployment record. This ensures traceability between design approval and execution. The output is a cross-referenced change record.
Role: Engineering Lead
Perform post-change validation
After deployment, the team validates that the implemented architecture matches the approved design. Any deviations are documented and reviewed. The output is a post-change validation note with date and reviewer.
Role: Senior Engineer
What You Need Before Starting
- Proposed change request or change ticket ID
- Access to architecture documentation tool (Confluence, Lucidchart, or Creately)
- Current-state system architecture diagrams
- SOC 2 CC8.1 change management criteria
Evidence Your Auditor Expects
- Architecture review request record with submission date and requester name
- Approved architecture diagram file showing version number and last modified date
- Completed risk and impact assessment document dated and signed by reviewer
- Change ticket or deployment record linking to the approved architecture review with timestamps
How This Looks In Your Tools
Confluence
In Confluence, navigate to the Engineering space and select “Create” > “Page.” Choose a predefined Architecture Review template or a blank page, then enter the change summary, scope, and review details.
Use “Insert” > “Files and images” to upload architecture diagrams or embed diagrams created in integrated tools. Apply page restrictions via “•••” > “Restrictions” to limit editing to reviewers. Record approvals using the “Comment” section or an approval macro with approver names and dates.
Lucidchart
In Lucidchart, click “+ New” > “Document” and select a network or system architecture template. Create diagrams showing current and proposed states, clearly labeling data flows and trust boundaries.
Use “File” > “Version History” to save a final version once approved. Share the document via “Share” > “Invite” with view or comment access, and copy the share link into the architecture review record or change ticket.
Creately
In Creately, select “Create New” > “Diagram” and choose an architecture or cloud infrastructure template. Build the proposed architecture using standard shapes and connectors, and add notes for security considerations.
Once finalized, select “File” > “Export” to PDF or PNG and ensure the export date is visible. Use “Share” > “Collaborators” to grant reviewer access and document approval comments within the diagram or linked review page.
Common Audit Findings
- Architecture changes not formally reviewed
- This occurs when teams move quickly and skip documented reviews for major changes. Prevent this by requiring an architecture review ID before approving any high-impact change ticket.
- Missing or outdated architecture diagrams
- Diagrams are often created but not updated after revisions. Enforce versioning and require a final modified date before approval.
- Lack of documented approval
- Verbal approvals are not auditable evidence. Require written approval with name, role, and date stored in the review record.
- No linkage between review and deployment
- Auditors cannot trace design approval to implementation. Always link the architecture review to the corresponding change or deployment record.