An Architecture Review Produces Decisions

A review is not complete when the diagram looks good.

It is complete when decision-makers can understand what needs attention, why it matters, what evidence supports it, and how a change will be verified.

Turn findings into a backlog

For each Week 17 gap, record:

finding ID
condition
asset/function
risk statement
supporting evidence
priority
owner
recommended treatment
change constraints
test/acceptance criteria
residual risk

This is the bridge between architecture and action.

Prioritize architectural work by dependency

Some fixes unlock others.

Example:

GAP-1 logging freshness unknown
GAP-2 privileged alert depends on logging
GAP-3 incident timeline depends on logging

Improving telemetry health verification may strengthen two downstream capabilities.

That does not automatically make it the highest risk, but the dependency should influence planning.

Distinguish tactical and structural fixes

Tactical

Quickly reduces a current exposure.

Example:

remove expired operator role

Structural

Changes the system/process so the same class of drift is less likely.

Example:

temporary roles receive enforced expiration + periodic review + session invalidation

Strong architecture reviews include both when appropriate.

Recommendations should preserve required function

Weak recommendation:

Lock everything down.

Strong recommendation:

Restrict direct maintenance-service binding to loopback because only the local proxy is a required consumer; verify proxy access remains functional and isolated remote direct access is denied in the lab model.

The second recommendation ties control to architecture and tests.

Prepare two levels of communication

Technical summary

Can include:

• trust boundaries;
• identities;
• ports/services;
• telemetry dependencies;
• control failure modes;
• test evidence.

Leadership summary

Should answer:

• what matters most?
• what is the consequence?
• what should happen next?
• who owns it?
• what evidence will close it?

Do not remove uncertainty merely to make the summary shorter.

Architecture-review walkthrough

Prepare a 5-minute defense:

1. Mission — what must the fictional system do?
2. Architecture — which components and trust boundaries matter?
3. Top three risks/gaps — why these first?
4. Controls — which mechanisms do they address?
5. Evidence — what proves the current state?
6. Next actions — owner + verification condition.
7. Limitations — what remains unknown?

This becomes the rehearsal for Week 18.

Review challenge questions

Your reviewer may ask:

Why is this control here?

Answer with the threat/failure path.

How do you know it works?

Answer with test evidence.

What happens if it fails?

Answer with failure detector/recovery.

What could this recommendation break?

Answer with required-function regression test.

What are you assuming?

Answer with your explicit unknowns/constraints.

If your artifact cannot answer these questions, it is not ready for final defense.

Finish the Defensive Architecture Review

Submit:

1. mission/required functions;
2. evidence-backed architecture diagram;
3. inventory and identities;
4. trust boundaries;
5. control/monitoring/recovery map;
6. six threat/failure paths;
7. five or more gaps;
8. prioritized remediation backlog;
9. top-three leadership summary;
10. verification criteria; and
11. limitations/known unknowns.

A strong conclusion:

The Week 17 review ties every major recommendation to a represented system boundary, risk path, and verification condition. It identifies shared control dependencies and unknowns instead of treating the presence of controls as proof of security.

Week 18 will test and defend this architecture rather than adding a new pile of features.