Security architecture review and redesign for the enterprise

The review examines how identity, network, cloud, endpoint, data protection and security operations fit together, and whether the design matches what runs in production. Work includes reading existing diagrams and configurations, interviewing owners, tracing trust boundaries and administrative paths, and checking each major control for an owner and a measure. Particular attention goes to places where domains meet, such as cloud identity federated to on-premises directories. Cloud-specific depth is available through cloud security.

Four documents. A current-state architecture that reflects production, including unowned tools and undocumented connections. A findings register ranking design weaknesses by the attack paths they allow. A target architecture with reference patterns for identity, network, cloud and data. A sequenced roadmap naming an owner, dependencies and a milestone for each step. An executive summary explains the decisions required and their order. Diagrams are delivered in editable form so your architects can maintain them.

Through capability overlap analysis. Every tool is listed against the capabilities it provides, the ones in use, its telemetry, its integrations, its owner and its renewal date. Overlaps and gaps then become visible on one page. A tool is retained when it covers a required capability that nothing else does, or does so measurably better. It is retired when another licensed tool covers the same ground and migration risk is acceptable. Each recommendation states what is kept, what goes and why.

A penetration test demonstrates specific exploitable weaknesses in what is built. An audit checks whether defined controls exist and operate against a standard. An architecture review asks whether the design itself is sound: where trust is assumed, which single failures expose everything, and which controls overlap or are missing. The three inform each other. Design weaknesses found in review are often confirmed by penetration testing, and test findings frequently trace back to an architectural cause.

Three, each for a different purpose. NIST CSF 2.0 organizes capabilities under six functions (Govern, Identify, Protect, Detect, Respond, Recover) and is used to check that no function is neglected. SABSA is a business-driven architecture method, and we use its practice of tracing every control back to a business requirement. Zero trust principles from NIST SP 800-207 guide access design by removing trust based on network location. Details are under the zero trust program.