📄 Control mapping is GRC meta-work

You wouldn't write API documentation before writing the API.

You wouldn't document a function before implementing it. Yet in GRC, we routinely map to compliance frameworks before understanding what controls we actually have.

We've inverted the natural order and it's costing us clarity, speed, and truth.

IN PARTNERSHIP WITH

Your security team’s guide to automated GRC

Manual evidence collection, scattered tools, and repetitive audits can take a real toll on security and GRC teams. This new GRC playbook, created by Drata and Tines, offers a practical look at how teams are shifting to continuous, automated compliance.

Inside, you’ll find:

• Detailed workflows for evidence collection, monitoring, audit prep, and vendor risk

• Implementation guidance from credential setup to scaling

• Best practices for building resilient, proactive GRC programs

The Framework-First Reality

The inversion: Starting from the end

Here's how GRC automation typically works today:

1. Pick your frameworks (ISO 27001, SOC 2, NIST CSF)

2. Import framework requirements into your GRC platform

3. Map requirements to controls

4. Generate evidence collection workflows

5. Export compliance reports

Platforms optimise for this flow. They advertise "multi-framework mapping" as a killer feature.

They promise automated crosswalks between ISO 27001 Annex A. controls and SOC 2 CCs. They generate coverage matrices showing which controls satisfy which requirements.

It feels productive. You're building a compliance architecture. You're creating traceability. You're demonstrating due diligence.

But you're doing meta-work, not actual work.

The fundamental mistake is treating frameworks as the source of truth when they're translation layers.

Think about it from a software engineering perspective:

• Controls = source code (what actually executes and produces outcomes)

• Frameworks = documentation (how we describe our code to specific audiences)

No engineer would write comprehensive API documentation, then try to build an API that matches it.

Yet that's exactly what framework-first GRC does:

# Framework-first (backwards)
ISO 27001 A.9.2.1: "User registration procedures"
→ Create control to satisfy requirement
→ Hope it actually works
→ Map to other frameworks

# Control-first (correct)
Actual control: "MFA enforced via Okta for all production access"
→ Verify it works (auth logs, penetration test)
→ Translate to frameworks as needed:
- ISO 27001: A.9.2.1, A.9.4.2
- SOC 2: CC6.1
- NIST CSF: PR.AC-7

The control exists independent of how we describe it. MFA either works or doesn't. Framework language is just... language. 

A translation layer for communicating the same reality to different audiences (auditors, control owners, executives).

When you start from frameworks, you're optimising for coverage reporting, not control effectiveness.

IN PARTNERSHIP WITH

Leave Compliance Firefighting in 2025 🔥

Make 2026 the year of continuous trust.

Drata automates the manual chaos so you can spend your time engineering—not extinguishing audit emergencies. Discover the power of continuous, automated control monitoring, real-time risk insights, and an AI-powered trust management platform that scales with your architecture.

Control Reality First

The right order: Document reality, don’t make documentation the reality

Here's the alternative: Start from what actually exists.

Step 1: Inventory actual controls

Not what should exist per some framework. What does exist right now:

Real controls in your environment

• GitLab branch protection rules

• AWS IAM policies

• Okta MFA enforcement rules

• CloudTrail logging configurations

• Dependabot security alerts

• SOC2 reports from vendors

• Employee background checks

• Encryption at rest (RDS, S3)

Step 2: Verify they work

Can you prove each control does what you claim?

• MFA enforced? Check auth logs for exceptions.

• Branch protection? Try to push to main without review.

• Encryption? Query the RDS instance config.

• Vendor security? When did you last review their SOC 2?

This is the only work that actually matters. Everything else is translation.

Step 3: Map to frameworks (as needed)

Now, when an auditor asks "How do you satisfy ISO 27001 A.9.2.1?", you can answer:

"We enforce MFA via Okta for all production access. Here's the policy config, here's 90 days of auth logs showing zero exceptions, here's our last pentest confirming it works."

Then you add metadata:

{
"control_id": "AC-001",
"control": "MFA enforced via Okta for all production access",
"evidence": ["okta_policy.json", "auth_logs_90d.csv", "pentest_2025_q4.pdf"],
"effectiveness": "verified_2026_01_15",
"framework_mappings": {
"iso27001": ["A.9.2.1", "A.9.4.2"],
"soc2": ["CC6.1"],
"nist_csf": ["PR.AC-7"]
}
}

The mappings are metadata. Commentary. Not the source of truth.

What This Looks Like in Practice

Playbook: Framework to stop being framework-first

Let's say you need SOC 2 compliance for a customer deal (surprise).

Framework-first approach:

1. Import SOC 2 trust service criteria (60+ requirements)

2. For each criterion, brainstorm "what control would satisfy this?"

3. Document controls (whether they exist or not)

4. Spend 6 weeks implementing controls you’ve just invented

5. Hope they actually work when auditor tests them

Control-first approach:

1. List controls you already have (GitHub, AWS, Okta, etc.)

2. Verify each one works (logs, tests, configs)

3. When auditor asks "How do you handle access control?", point to Okta MFA

4. Auditor says "That satisfies CC6.1"

5. You add that mapping to your metadata

One approach takes 6 weeks and creates controls to match a framework. The other takes 2 weeks and describes existing controls in framework language.

The control effectiveness is identical in both cases. The only difference is whether you started from reality or from a document.

When Framework-First Makes Sense

This isn't absolutist.

There are cases where framework-first is the right call:

Greenfield with no existing controls

If you're building a new system from scratch, frameworks provide a reasonable checklist. You don't have "control reality" yet, so framework requirements are a decent starting point.

But even here, implement the control first, then map it. Don't create a framework mapping in your GRC platform and call it done.

Frameworks as business requirements

Sometimes frameworks aren't just translation layers, they're contractual requirements. FedRAMP doesn't care about your "actual controls"; they care about NIST 800-53 control mappings (it’s changing now thanks to FedRAMP 20x though which is amazing)

Fine. Map to 800-53. But still start from reality. Document your controls, verify they work, then add the NIST control IDs as metadata.

Compliance-driven industries

Healthcare, finance, defense. Heavily regulated industries where frameworks have legal weight. Framework compliance isn't optional; it's the business you're in.

Even here: Implement actual controls first. The framework mapping is still meta-work, but it's meta-work the regulator requires. Do it last, not first.

The heuristic:

• Framework-first if you have nothing (greenfield)

• Control-first if you have anything (90% of cases)

• Always verify controls work before mapping them

Your Move

The application: what to put in place now.

Here's how to escape the framework mapping trap:

If you're starting from scratch:

1. Pick one framework (not five)

2. Use it as a checklist, not a data model

3. Implement controls, verify they work, document them

4. Add framework IDs as metadata afterward

If you're already framework-first:

1. Inventory your actual controls (scripts, configs, policies)

2. For each framework requirement, ask: "What control actually does this?"

3. If no control exists, admit it (gap)

4. If control exists, verify it works, then link it

5. Treat framework mappings as tags, not truth

If you're buying a GRC platform:

1. Ask: "Can I model controls independent of frameworks?"

2. Ask: "Can I link evidence to controls, not just boiler-plae framework requirements?"

3. Avoid platforms that require framework selection before control documentation

The goal isn't to eliminate frameworks. They're useful for communication. The goal is to stop treating them as the source of truth.

Your controls are the source of truth. Frameworks are just how you describe them to auditors.

Start from reality. Translate to compliance. Not the other way around.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!