A security architecture assessment examines how a service is designed, deployed and operated. It should identify assets, trust boundaries, data flows, dependencies, threats and control gaps. The outcome is a prioritised set of design decisions and actions—not simply a checklist score.
Define scope and business context
Identify the service owner, business purpose, users, data classifications, availability needs, regulatory obligations and critical dependencies. Confirm whether the assessment covers on-premises infrastructure, cloud services, SaaS integrations, endpoints or third parties. Record assumptions and exclusions.
Map architecture and data flows
Create current diagrams showing identity providers, applications, network zones, endpoints, APIs, databases, external integrations and administrative paths. Mark where sensitive data is collected, processed, stored and transferred. Validate diagrams with engineers and operators rather than relying only on old documentation.
Threat modelling
Consider threat actors, entry points, privilege boundaries, misuse cases and failure scenarios. Ask how an attacker could obtain credentials, move laterally, access data, alter configurations or disrupt availability. Evaluate existing preventive, detective and recovery controls. Use a recognised methodology appropriate to team maturity.
Assess control domains
Review identity, network, endpoint, application, cloud, data protection, logging, vulnerability management, backup, incident response and supplier access. Evaluate both design and evidence of operation. A policy document does not prove that a control is deployed or effective.
Prioritise recommendations
Rate findings by likelihood, impact, exposure and compensating controls. Each recommendation should identify the affected asset, risk statement, proposed action, owner, priority and target date. Separate urgent containment actions from longer-term architecture improvements.
Validate and maintain
Review remediation evidence, update diagrams and reassess after major changes. Track accepted risks with an accountable owner and expiry or review date. Architecture is not static: new integrations, cloud services and business processes can change the threat model.
- Confirm the control has a named owner and documented business purpose.
- Validate configuration against current vendor guidance and organisational policy.
- Test expected and denied access paths; retain evidence of the result.
- Monitor exceptions, failures and configuration changes.
- Review the control after material infrastructure or business changes.
A useful assessment connects technical design to business risk and produces actions that can be owned, prioritised and verified.