Auditors and certifiers do not build anything. Why are they stakeholders, and what do they need?
They have to examine cyber systems and draw conclusions about quality and risk — which requires a picture of the components, how they work, how they are wired together and how they interact. A well-structured, documented architecture is exactly that picture.
Audit and control functions — internal audit, external financial auditors, certification bodies for standards such as ISO/IEC 27001 — all face the same problem: they must form a defensible judgement about a system they did not build, in a limited time, from evidence.
That judgement needs four things:
- System components — what is there at all.
- Functions — what each part does.
- Interconnections (Verschaltungen) — how they are wired together.
- Interactions (Wechselwirkungen) — how they affect each other, which is where the interesting findings usually are.
If the organisation cannot supply this, the audit does not stop — it proceeds on what the auditors can reconstruct themselves, with the gaps recorded as findings. Undocumented is, for audit purposes, indistinguishable from uncontrolled.
The reverse is a genuine and often decisive benefit of doing architecture work at all: good documentation converts audit from an archaeology project into a review. It shortens audits, reduces findings that are really documentation gaps, and gives the organisation a place to show why a design is the way it is — which is frequently the answer an auditor is actually looking for.
Go deeper:
Wikipedia — Information technology audit — what auditors must establish and the evidence they need to establish it.