An organisation ends up with several frameworks at once. Each arrives as its own spreadsheet, its own evidence request, its own owner. The same access review gets gathered three times because three documents named it differently. That is the version of audit management that consumes a quarter and leaves the organisation no better controlled than it started.
Controls are yours, frameworks are theirs
The fix is a layer of indirection that most teams skip. You maintain one set of controls describing what you actually do. Frameworks map onto them:
controls
id, description, owner, frequency, evidence_type
framework_requirements
framework -- soc2 | iso27001 | dpdp | customer_x
requirement_ref -- CC6.1 | A.9.2.5 | Q14
control_id
notes
Many-to-many, deliberately. One quarterly access review satisfies a requirement in each framework. Adding a fourth framework becomes a mapping exercise against controls that already exist and already have evidence — usually a day, not a quarter.
Treat the mapping the way you treat the evidence itself: append-only, because a trail an administrator can edit is not a trail. You will eventually need to explain what you claimed to an assessor two years ago, and a table that only holds the current answer cannot tell you.
The gap analysis becomes a query
“What do we need for ISO that we do not already have” is a left join: requirements with no mapped control, or mapped controls with no evidence in the period. The second case is the common one, and it is the reason enforcement has to be designed to emit records — zero trust is only worth anything if it produces evidence a mapping can point at.
That is the question everyone answers manually with a spreadsheet and a colour scale. It is a query if the mapping exists, and it is answerable continuously rather than at the start of an engagement.
Do not let a framework dictate your controls
The temptation is to structure controls to mirror whichever framework came first. Then the second framework does not fit and you end up with two parallel sets, which is the situation the mapping was meant to avoid.
Describe what you actually do, in your own language, at whatever granularity matches how the work is really owned. Map afterwards. A control that does not correspond to something a named person actually does is a fiction that will fail on inspection anyway.
Ownership is per control, not per framework
Assigning “ISO 27001” to a compliance manager guarantees they spend the year chasing engineers. Assigning the access review control to the platform lead, with a cadence and a due date, puts the work with the person who does it.
Compliance then coordinates and reports rather than collecting, which is the only version of the role that scales past one framework.