Design assurance
Assessing the design rather than the settings, because some problems cannot be patched and have to be drawn differently.
Testing and scanning both work at the level of what is deployed. They will find an unpatched host or a weak permission, and both are worth finding. Neither will tell you that your network has no meaningful internal boundary, that every application authenticates against one directory with no tiering, or that your logging stops at the edge of the environment where an incident would actually unfold.
Those are design problems. They do not appear as findings because nothing is misconfigured: the system is working exactly as built. They surface as the reason a small incident became a large one, and they are the most expensive class of problem to fix late.
What we do
How authentication and authorization are structured across the estate: directory design, privileged access tiering, trust between domains and tenants, and the paths between an ordinary account and an administrative one. Identity is the control plane, and its design decides how far a foothold reaches.
Whether the network has boundaries that mean anything, where they sit, and what actually enforces them. For regulated environments the boundary is also the assessment scope, so drawing it deliberately is what keeps scope from expanding into everything you own.
Following the regulated data through the systems that touch it, including the ones nobody lists: the reporting database, the backup target, the developer laptop. Data flow diagrams are a control requirement in most frameworks and are usually the artefact that reveals scope was wrong.
Whether you would see an incident, and where the blind spots are. Most environments log the perimeter well and the interior poorly, which is the wrong way round for anything that starts with a valid credential.
Whether the architecture can survive losing a component, and whether recovery has been tested rather than documented. Overlaps with the availability side of IT architecture review, and the two are usually run together.
See also: IT Services
A design worth moving toward and a sequence for getting there that accounts for what you can actually fund and staff. A review that ends at a list of problems has done half the work.
Process
Build an accurate picture of what exists, which usually means correcting the diagrams rather than reading them. Architecture documentation is out of date in almost every environment.
What the architecture has to satisfy: compliance obligations, contractual commitments, availability targets, and the threats that actually apply to you.
Compare the design against those requirements, working through identity, segmentation, data flow, logging, and recovery in turn.
Trace what a realistic compromise would reach given the current design. This is what turns an architectural observation into a funded decision.
Target architecture with a roadmap ordered by risk reduction per unit of effort, rather than by how the review happened to be structured.
Deliverables
Every engagement produces documentation you can hand to an auditor, a customer, or your own board without translating it first.
A clean penetration test on a flat network is a real result and a limited one. The design question is separate and worth asking on its own.