Security Architecture
Design security into the systems, applications and infrastructure that support your business.
Architecture decides what is possible. Once a boundary is drawn and systems are built either side of it, the security options available afterwards are constrained by that choice — and no amount of testing or monitoring recovers what the design gave away.
Architecture review is about examining those decisions while they can still be changed, or understanding what they cost when they cannot.
What is security architecture work?
Security architecture work reviews how a system is actually built, including the parts not on the diagram, designs controls into a system rather than around it, examines trust boundaries and what each side assumes, how identity flows through the system, application- and cloud-level design decisions, where sensitive data sits and what actually protects it, and which controls belong where versus which are theatre, producing practical, sequenced recommendations. Some findings cannot be fixed where they are found — the vulnerability is real, but the cause is a trust boundary in the wrong place or a service holding more access than its function requires, so fixing the instance without addressing the architecture means the same finding reappears later under a different name. This is advisory and design work: recommendations are proposals for your team to evaluate, not changes applied directly to production systems.
Who needs it? Organizations facing an expensive-to-reverse design decision where security has not been part of the conversation, organizations re-platforming or migrating where trust boundaries are about to move, organizations where the same class of finding keeps appearing across assessments, and organizations integrating an acquired system with different architectural assumptions.
How TMG Security helps. TMG Security reviews architecture, trust boundaries, identity flows and data protection, and delivers sequenced recommendations leadership can act on.
Some findings are not bugs, they are decisions
A recurring pattern in testing is a finding that cannot be fixed where it was found. The vulnerability is real, but the cause is a trust boundary in the wrong place or a service holding more access than its function requires.
Those are architecture problems wearing the costume of a bug. Fixing the instance leaves the class intact, which is why the same finding reappears in the next assessment under a different name.
How this is put together.
What architecture work covers
SCOPE OF SERVICEAdvisory and design work. Recommendations are proposals for your team to evaluate, not changes we apply to production systems.
How a review runs
- 01MAPEstablish the architecture as built, not as documented.
- 02BOUNDARIESIdentify where trust changes and what is assumed.
- 03ASSESSExamine controls at each boundary and the gaps between.
- 04MODELConsider how a weakness at one point propagates.
- 05DESIGNPropose changes that address causes rather than instances.
- 06SEQUENCEOrder the work by dependency, cost and impact.
When Should Architecture Be Reviewed?
Output leadership can act on.
Which of these apply depends on engagement scope.
Where current practice differs from the requirements that apply to you.
Which controls address which requirements, and where nothing does.
What the gaps mean in terms of risk, not just non-conformity.
What needs to exist in writing, and what it needs to say.
Whether you could demonstrate a control operates, if asked.
Sequenced work, with dependencies made explicit.
A version of the findings that a board or exec team can act on.
Adjacent parts of the programme.
Questions we get asked before an engagement.
No, and expecting it usually delays the work indefinitely. Part of a review is establishing how the system actually works — the gap between documented and real architecture is often where the interesting findings sit.
A test finds what is exploitable in the system as built. A review examines whether the system should have been built that way. Testing tells you about instances; architecture work addresses the class.
That is the best case. Reviewing a proposed architecture is far cheaper than reviewing a built one, because the output is a design change rather than a migration.
We work with your team on design and sequencing; implementation stays with the people who own and operate the systems. That boundary matters — the team that runs it needs to understand and agree with the change.
Discuss Security Architecture
Bring an architecture you are about to build or about to change significantly. That is where a review earns its cost.