1. Purpose
The Security Architecture Review Template is used to assess whether a project’s proposed architecture adequately addresses information security requirements, risks, data protection, access control, infrastructure security, application security, monitoring, resilience, and applicable compliance obligations.
The review should identify security weaknesses before implementation or production deployment, rather than relying only on testing after the system has been built.
The review should answer:
- What is being built?
- What information does it process?
- Where does the information flow?
- What systems and components are involved?
- Where are the security boundaries?
- What threats and risks exist?
- What security controls are required?
- Are the controls designed appropriately?
- What security gaps or exceptions remain?
2. Architecture Review Information
| Field | Details |
|---|---|
| Project Name | [Project Name] |
| Project ID | [Project ID] |
| Architecture Version | [Version] |
| Review ID | SAR-XXXX |
| Business Owner | [Name] |
| Project Manager | [Name] |
| Technical Owner | [Name] |
| Security Reviewer | [Name] |
| Architect | [Name] |
| Review Date | [Date] |
| Project Phase | [Design / Development / Pre-Production] |
| Environment | [AWS / Azure / GCP / On-Premises / Hybrid] |
| Data Classification | [Public / Internal / Confidential / Restricted] |
| Criticality | [Low / Medium / High / Critical] |
| Review Status | [Open / Conditional / Approved / Rework Required] |
3. Review Scope
Define the components covered by the architecture review.
In Scope
- Applications
- APIs
- Databases
- Cloud infrastructure
- Networks
- Identity and access management
- Authentication
- Data flows
- Third-party integrations
- CI/CD pipeline
- Logging and monitoring
- Backup and recovery
- Security services
- Administrative access
Out of Scope
| Component | Reason |
|---|---|
| [Component] | [Reason] |
Any significant component excluded from the review should have a documented reason.
4. Architecture Documentation
Confirm that the required architecture information is available.
| Document / Diagram | Available | Reviewed | Comments |
|---|---|---|---|
| High-Level Architecture Diagram | ☐ | ☐ | |
| Detailed Architecture Diagram | ☐ | ☐ | |
| Network Diagram | ☐ | ☐ | |
| Data-Flow Diagram | ☐ | ☐ | |
| Data Classification | ☐ | ☐ | |
| Asset Inventory | ☐ | ☐ | |
| API Documentation | ☐ | ☐ | |
| Cloud Architecture | ☐ | ☐ | |
| Third-Party Integrations | ☐ | ☐ | |
| Disaster Recovery Architecture | ☐ | ☐ | |
| Security Architecture | ☐ | ☐ |
5. Business and Security Context
Document the purpose of the system and its security context.
Business Purpose
[Describe what the system does.]
Users
- Employees
- Customers
- Administrators
- Developers
- Suppliers
- Third-party users
- Service accounts
Information Processed
- Customer information
- Personal data
- Financial information
- Authentication information
- Business information
- Source code
- Security information
Critical Business Functions
[Describe the business processes dependent on the system.]
6. Data-Flow Review
Review how information enters, moves through, is processed, stored, and leaves the system.
Data Flow
User → Application → API → Processing Layer → Database → External Service
For each flow, document:
| Flow ID | Source | Destination | Data | Classification | Protocol | Encryption | Authentication |
|---|---|---|---|---|---|---|---|
| DF-001 | Customer | Web App | Customer Data | Confidential | HTTPS | TLS | MFA |
| DF-002 | App | RDS | Customer Records | Restricted | TLS | Encryption | IAM |
| DF-003 | App | Payment Provider | Payment Data | Restricted | HTTPS | TLS | API Auth |
Review Questions
- Is the data flow documented?
- Is sensitive information identified?
- Is data encrypted in transit?
- Is sensitive data encrypted at rest where required?
- Are unnecessary data transfers avoided?
- Are external transfers controlled?
- Are third-party data flows understood?
- Are data retention requirements considered?
7. Trust Boundaries
Identify security boundaries within the architecture.
Examples:
- Internet → Web application
- Customer → Application
- Application → Database
- Corporate network → Cloud
- Production → Development
- Organization → Third-party supplier
- User → Administrative environment
For each boundary, identify:
- Authentication
- Authorization
- Network controls
- Encryption
- Monitoring
- Input validation
- Logging
- Security controls
8. Network Security Review
Review the network architecture.
Checklist
- ☐ Network segmentation implemented where required
- ☐ Public-facing systems identified
- ☐ Private systems identified
- ☐ Internet exposure minimized
- ☐ Security groups/firewalls configured
- ☐ Administrative interfaces restricted
- ☐ Database not unnecessarily exposed
- ☐ Network traffic restricted by business need
- ☐ Secure protocols used
- ☐ Remote access secured
- ☐ Network monitoring implemented
- ☐ DNS security considered
- ☐ DDoS protection considered where applicable
- ☐ WAF considered for internet-facing applications
Network Review Findings
| Finding ID | Area | Observation | Risk | Recommendation | Owner |
|---|---|---|---|---|---|
| AR-001 | Network | Database publicly accessible | High | Restrict to application network | Cloud Lead |
9. Identity and Access Architecture
Review how users and systems authenticate and receive access.
Review Areas
- Authentication
- Authorization
- MFA
- RBAC
- Least privilege
- Privileged access
- Service accounts
- API credentials
- Administrative access
- Joiner/mover/leaver integration
- Access reviews
- Session management
Questions
- Are users uniquely identified?
- Is MFA required for privileged or sensitive access?
- Are privileged accounts separated?
- Is least privilege implemented?
- Are service accounts controlled?
- Are credentials securely stored?
- Are inactive accounts removed?
- Is access logged?
- Is privileged activity monitored?
10. Application Security Architecture
Review the application’s security design.
Checklist
- ☐ Secure authentication
- ☐ Authorization enforced server-side
- ☐ Input validation
- ☐ Output encoding
- ☐ Secure session management
- ☐ API authentication
- ☐ API authorization
- ☐ Rate limiting
- ☐ Error handling
- ☐ Secure logging
- ☐ Secrets not stored in source code
- ☐ Dependency management
- ☐ Secure coding standards
- ☐ Security code review
- ☐ Security testing
- ☐ Protection against common application attacks
- ☐ Security headers where applicable
Security architecture should be reviewed before relying solely on penetration testing to identify design weaknesses.
11. API Security Review
For systems using APIs, review:
| Area | Review |
|---|---|
| Authentication | ☐ |
| Authorization | ☐ |
| TLS | ☐ |
| Input validation | ☐ |
| Rate limiting | ☐ |
| API gateway/security controls | ☐ |
| Token management | ☐ |
| Secrets management | ☐ |
| Logging | ☐ |
| Monitoring | ☐ |
| Error handling | ☐ |
| API versioning | ☐ |
| Third-party API security | ☐ |
12. Database Security Architecture
Review database security.
Checklist
- ☐ Database access restricted
- ☐ Public exposure prevented unless justified
- ☐ Strong authentication
- ☐ Least privilege
- ☐ Encryption at rest
- ☐ Encryption in transit
- ☐ Database activity logging where appropriate
- ☐ Backup configured
- ☐ Backup security considered
- ☐ Sensitive fields protected where required
- ☐ Production access restricted
- ☐ Administrative access monitored
- ☐ Retention requirements considered
13. Cloud Security Architecture
For AWS, Azure, or GCP environments, review applicable services and security controls.
AWS Example
| Area | Example Security Consideration |
|---|---|
| AWS Accounts | Separation of production/non-production |
| IAM | Least privilege and MFA |
| Organizations | Account governance |
| VPC | Network segmentation |
| Security Groups | Restricted inbound/outbound access |
| S3 | Block unnecessary public access |
| RDS | Private access and encryption |
| KMS | Encryption key management |
| Secrets Manager | Secure credential storage |
| CloudTrail | API activity logging |
| CloudWatch | Monitoring and alerting |
| WAF | Web application protection |
| GuardDuty | Threat detection where applicable |
| Security Hub | Security findings aggregation where applicable |
| Backup | Backup and recovery controls |
The actual services should be based on the project’s architecture rather than implemented simply because they appear in a checklist.
14. Data Protection and Privacy
Review:
- Data classification
- Data minimization
- Encryption
- Data retention
- Data deletion
- Data access
- Data transfer
- Privacy requirements
- Customer contractual requirements
- Cross-border transfers
- Backup copies
- Logging containing personal information
Where personal data is involved, confirm that applicable privacy requirements have been identified and assessed.
15. Secrets and Key Management
Review how secrets and cryptographic keys are managed.
Checklist
- ☐ Secrets stored in approved secret-management solution
- ☐ No hard-coded credentials
- ☐ No credentials committed to source control
- ☐ Encryption keys protected
- ☐ Key access restricted
- ☐ Key rotation considered
- ☐ Secrets rotation considered
- ☐ Access to secrets logged
- ☐ Production secrets separated from development
- ☐ Emergency credential rotation procedure available
Example
For an AWS SaaS application:
Application → AWS Secrets Manager → Database Credential
rather than:
Application → Hard-coded database password
16. Logging and Monitoring Architecture
Review whether security-relevant events can be detected and investigated.
Events to Consider
- Authentication
- Failed authentication
- Privileged access
- Administrative actions
- Configuration changes
- API activity
- Data access
- Security events
- Application errors
- Cloud activity
- Security alerts
Review
- ☐ Logging enabled
- ☐ Logs protected from unauthorized modification
- ☐ Appropriate retention
- ☐ Central monitoring
- ☐ Alerting
- ☐ Time synchronization
- ☐ Log access restricted
- ☐ Sensitive information in logs controlled
- ☐ Security events escalated
17. Backup and Recovery Architecture
Review:
- Backup frequency
- Backup scope
- Backup encryption
- Backup access
- Backup isolation
- Backup retention
- Restoration testing
- Recovery objectives
- Disaster recovery
- Failover
- Recovery dependencies
Questions
- Can critical information be recovered?
- Are backups protected from unauthorized access?
- Could ransomware affect backups?
- Has restoration been tested?
- Are recovery procedures documented?
18. Availability and Resilience
Assess whether the architecture provides appropriate resilience.
Consider:
- Single points of failure
- Availability zones
- Redundancy
- Load balancing
- Failover
- Disaster recovery
- Capacity
- Dependency failures
- Third-party outages
- Cloud-region dependency
- Recovery Time Objective (RTO)
- Recovery Point Objective (RPO)
The required level of resilience should be based on business requirements and risk.
19. Third-Party Integration Review
Identify external dependencies.
| Supplier | S