Core Idea
Enterprise GRC automation is coordination architecture. At scale, the hard part is rarely a single connector. It is the number of systems, owners, exceptions, evidence formats, frameworks, and review loops that must remain coherent as the organisation changes.
A small proof of concept might pull one AWS setting into one dashboard. Enterprise reality asks who owns the data, how exceptions travel, which business units differ, and how framework mappings survive change. The teaching consequence is to look for coordination debt before connector count.
Use In Teaching
Invoke this card when a learner compares startup-friendly automation with enterprise constraints, or when they assume a proof of concept will scale linearly. It helps them identify data ownership, workflow boundaries, and integration debt.
Use it to test whether the learner understands scale. Ask what changes when the workflow crosses regions, subsidiaries, cloud providers, evidence owners, and frameworks. If their design only works for one friendly team and one clean data source, it is not yet enterprise architecture.
A reviewer should check that Enterprise GRC Automation leaves the learner with one artefact to inspect, one assumption to test, and one behaviour to observe in their local context. That keeps the concept practical instead of turning it into vocabulary.
Contrast
This is not bigger tooling for its own sake. It pushes back against both DIY heroics and vendor fantasies. Enterprise automation must respect complexity without surrendering to it.
Practice Prompt
What breaks first when your neat GRC automation has to support three business units, two clouds, and overlapping frameworks?