Use this when a second framework arrives, or when the evidence calendar already shows the same artefact requested by two audits. You get three files in a new folder, ./multi-framework-overlap-map/: a spreadsheet you can open in Excel with the company's own controls as rows and each framework as a column (control-map.csv), a second spreadsheet listing each piece of evidence to collect once and which audits it serves (evidence-plan.csv), and short notes on sources, coverage and the decisions you need to make (mapping-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. A mapping says where evidence can be reused; it never says one framework satisfies another.
Inputs to gather
Read first: the existing control list (from a compliance platform export, a control matrix or the applicability statement), the policies, the audit calendar and the last request lists from each auditor or assessor. Ask the reader, in one message: which frameworks are in play and with what outcome (certificate, attestation report, legal obligation, voluntary profile), which one has the nearest deadline, and which source texts they hold (licensed standards, criteria documents, official law).
Step 1: build the internal control set first
Write the company's controls in its own words in the control spreadsheet (control-map.csv), one practice per row, with its own ids (for example CTL-ACC-03). Each row has: a control statement saying who does what, how often, on which systems; an owner role; a frequency; and the artefact that proves it ran. Merge duplicates found across existing framework-specific lists. Aim for 60 to 150 controls for a company of 20 to 300 people; fewer means the rows are too coarse to evidence, more means they are split by framework instead of by practice.
Step 2: map each control to framework references
For each framework, record the reference by bare identifier only, taken from the source text the reader holds or from a framework lookup, never from memory. For each pair record a match strength:
- Covers: the control, as operated, fully supports the reference. Use only after reading both texts.
- Partial: supports it with a stated difference (scope, frequency, a missing element). Write the difference.
- Contributes: helps but is not enough alone. Where several controls contribute to one reference, judge whether the combination covers it, record that judgement, and name one control as the owner of the reference.
Do not copy requirement text into the map. One control usually maps to one to five references per framework; a control mapped to twenty is too broad to sample.
Step 3: find what does not overlap
List, per framework, the items no internal control covers yet, and the items unique to one framework. Typical examples are legal notification deadlines that exist only in a regulation, report sections specific to an attestation, management-system elements specific to a certification, and outcome-level items in a voluntary framework that the company chose to target. For public law in scope, cite the article when it helps the owner find it, for example GDPR Article 30 for records of processing, GDPR Article 32 for security of processing, GDPR Article 33 for breach notification to the authority, NIS 2 Article 21 for risk management measures and NIS 2 Article 23 for incident reporting. Each gap becomes a new internal control or an action, not a framework-specific side process, with a due date set by the nearest audit or legal deadline. Where a certification expects an applicability statement, a framework item with no internal control needs either a new control or a recorded reason for excluding it.
Step 4: plan evidence once
Write the evidence spreadsheet (evidence-plan.csv) with one row per artefact: artefact, internal control ids, every framework reference it supports, owner role, collection frequency, retention, and the period each audit samples. Use the most demanding frequency and the longest audit period among the mapped frameworks, so one collection serves all audits. Flag artefacts where frameworks pull in different directions (one wants a quarterly review, another an annual one; one audit period ends in a different month) and propose one schedule. Check the format too: if one auditor accepts a screenshot and another wants the system record or ticket, collect the stronger format once.
Step 5: write the notes
Write the notes (mapping-notes.md): the sources used for each framework with their edition or version and the date of any lookup (a map silently rots when a framework is revised), the count of controls and references, the coverage per framework (covers, partial, none), the unique items, and the decisions the reader needs to make. Ask before overwriting any file.
What good looks like
- The company's controls are the spine; frameworks are columns. The common mistake is a framework-to-framework crosswalk table that leaves each team collecting evidence the old way. The tell: the map has framework ids on both sides and no owner or artefact column.
- Match strength is honest. A map where everything "covers" everything was not read; partial matches with a written difference are what auditors and assessors trust.
- Unique items are named early. They are where dual programmes overrun.
- The evidence plan shrinks the calendar: the reviewer can count fewer distinct requests than before.
- Each reference in the map can be traced to the source text the reader holds or to a recorded lookup answer.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-multi-framework-overlap-map
Rules
- MUST write internal controls in the company's own words before mapping any framework.
- MUST take every framework reference from a source the reader holds or from a framework lookup, and record which.
- MUST write outputs only inside
./multi-framework-overlap-map/ and ask before overwriting.
- NEVER mark a pair as covers without reading both the control as operated and the reference text.
- NEVER copy requirement text or official control titles into the map; use bare identifiers.
- NEVER tell the reader that one certificate or report satisfies another framework.