Beyond Spreadsheet Crosswalks

Organizations rarely operate under a single cybersecurity framework.

A SaaS provider may need ISO 27001 for its information security management system, SOC 2 to satisfy customer expectations, GDPR for privacy obligations, and NIS2 because of its sector or customer base. A defense supplier may need to consider NIST SP 800-171, CMMC, contractual requirements, and its existing ISO-based controls at the same time.

The problem is that these frameworks are not completely independent. They frequently ask organizations to perform similar activities using different terminology, structures, and levels of detail.

This is where framework cross-mapping becomes valuable.

However, identifying similar requirements is only the beginning. To make cross-mapping reliable, reusable, and suitable for automation, organizations also need to know where a relationship came from, how strong it is, which framework versions it applies to, and where important gaps remain.

Two NIST initiatives are particularly relevant to this challenge: the National Online Informative References Program, better known as OLIR, and the OSCAL Control Mapping Model.

They address different parts of the same problem.

Why multi-framework compliance creates unnecessary work

Traditional compliance programs are often organized around individual frameworks.

One spreadsheet contains the ISO 27001 controls. Another tracks NIS2 requirements. A third is maintained for a customer questionnaire or an upcoming SOC 2 audit. Evidence, policies, control descriptions, and implementation notes are copied between them.

This makes it easy to treat every new framework as a completely new compliance program.

Cross-mapping identifies common or overlapping requirements so that existing controls and evidence, such as policies, logs, screenshots, and procedures, can be reused where appropriate. The practical benefits extend beyond reducing duplicate work. Cross-mapping can also improve audit preparation, reporting, risk visibility, and the ability to respond to regulatory changes.

The most valuable output is often not the overlap itself, but the delta.

An incident-response process may support requirements in ISO 27001, SOC 2, and NIS2. That does not mean the requirements are identical. One framework may require specific reporting timelines, another may focus on governance responsibilities, and another may expect particular evidence during an audit.

A useful mapping therefore needs to answer two questions:

1. What can be reused?
2. What is still missing?

This distinction separates a reliable crosswalk from a simple table of supposedly equivalent controls.

What is OLIR?

OLIR stands for Online Informative Reference and is part of NIST's National Online Informative References Program.

The program enables subject matter experts to describe relationships between elements of their own standards, frameworks, products, or guidance and elements of supported NIST documents. These NIST documents are referred to as focal documents and can include publications such as the NIST Cybersecurity Framework, NIST SP 800-53, or the NIST AI Risk Management Framework.

An OLIR might, for example, connect a requirement from an industry framework to a NIST CSF 2.0 Subcategory.

OLIR offers more than a spreadsheet structure. It provides:

• A standardized approach for expressing mapping assertions
• Templates for supported NIST focal documents
• Metadata about the submitting organization and the mapped documents
• A centralized public catalog
• Draft and final publication statuses
• A public review process
• Information about whether the mapping was created by the owner of a document or by a third party

NIST distinguishes between three OLIR mapping styles: concept crosswalks, set-theory relationship mappings, and supportive relationship mappings.

For detailed compliance crosswalks, set-theory mappings are particularly interesting. Instead of merely saying that two requirements are related, they can describe whether one is equal to, a subset of, a superset of, or partially intersects with another.

OLIR therefore provides two things that many internal mapping projects lack: discoverable mapping content and a governance structure around that content.

What is the OSCAL Control Mapping Model?

OSCAL, the Open Security Controls Assessment Language, provides machine-readable models for representing control catalogs, profiles, system security plans, assessment plans, assessment results, and related compliance information.

The OSCAL Control Mapping Model extends that ecosystem by providing a structured representation of relationships between controls and control elements from different documentary sources.

Unlike a narrative crosswalk, the model is designed to be processed by software. It can be represented in JSON, YAML, or XML and can map controls or individual control statements from OSCAL catalogs and profiles.

Its relationship types include:

• equal-to
• equivalent-to
• subset-of
• superset-of
• intersects-with
• no-relationship

The model can also describe whether a mapping was based on syntactic similarity, semantic meaning, or functional outcome.

This matters because two requirements may look similar while producing different operational results. Conversely, requirements that use completely different language may still serve almost the same security function.

The model can additionally capture provenance, responsible parties, status, confidence, coverage, gaps, and whether the mapping was produced manually, automatically, or through a hybrid process. This makes it suitable not only for displaying crosswalks but also for automated gap analysis, change-impact analysis, validation, and reuse across compliance workflows.

OLIR and OSCAL are not competing approaches

It is tempting to ask whether an organization should use OLIR or the OSCAL Control Mapping Model.

In practice, they solve different problems.

OLIR is primarily a program, catalog, submission process, and source of mapping assertions. It helps organizations find and publish mappings involving NIST focal documents.

The OSCAL Control Mapping Model is a technical data model. It determines how mapping relationships can be stored, exchanged, validated, and processed inside a system.

OLIR can tell a platform that an expert or organization has asserted a particular relationship. OSCAL can make that relationship part of a larger, computable compliance system.

OSCAL is also more general in scope. An OSCAL Mapping Collection can connect any suitable OSCAL catalogs or profiles. It is not restricted to relationships involving a NIST focal document.

This means an organization could use OSCAL to represent direct relationships such as:

• BSI IT-Grundschutz to ISO 27001
• NIS2 to ISO 27001
• DORA to an internal control library
• Customer-specific requirements to existing organizational controls

These mappings would not necessarily qualify as official OLIR submissions, but they could still use comparable relationship concepts and be stored consistently through OSCAL.

How the two can work together

A practical implementation could treat OLIR as one of several external mapping sources and OSCAL as the canonical internal representation.

OLIR mappings
BSI or regulatory crosswalks
Publisher-provided mappings
Expert-created mappings
Customer-specific mappings
AI-generated mapping suggestions
                ↓
      Import and normalization
                ↓
   Framework and version resolution
                ↓
     OSCAL Mapping Collections
                ↓
 Review, approval, and confidence
                ↓
Gap analysis, evidence reuse, and impact analysis

When importing an OLIR, a platform would identify the reference document and focal document, resolve their element identifiers against the corresponding OSCAL catalogs, and translate each relationship into an OSCAL mapping entry.

The original OLIR should remain attached as provenance. Users should be able to see:

• Who created the mapping
• Which versions were compared
• Whether the publisher owned either source
• Whether the mapping is draft or final
• What mapping method was used
• Whether it has been reviewed internally

This makes mappings traceable rather than treating them as universal facts.

Cross-mapping should not become blind equivalence

Automation creates a risk that organizations begin treating mappings as proof that one implementation automatically satisfies every related requirement.

That conclusion is rarely justified.

A crosswalk describes relationships between requirements. It does not automatically prove that an organization has implemented those requirements effectively.

Evidence may also be reusable without being sufficient. A backup policy could support several frameworks, but one framework might additionally require restoration tests, defined recovery objectives, specific retention periods, or evidence of management review.

Reliable cross-mapping therefore requires:

• Statement-level granularity where possible
• Explicit framework versions
• Documented relationship types
• Gap descriptions
• Provenance
• Confidence levels
• Human review for consequential decisions

Derived relationships deserve particular caution. OLIR can generate Derived Relationship Mappings between two reference documents by comparing how both relate to a shared NIST focal document. NIST describes these as non-authoritative starting points rather than verified direct crosswalks.

They can accelerate analysis, but they should generate review tasks, not automatic compliance claims.

From static crosswalks to reusable compliance infrastructure

The practical argument for cross-mapping is compelling: organizations should not repeatedly create the same controls, gather the same evidence, and maintain disconnected compliance programs for every framework. A centralized repository and scalable automation can reduce duplication and make gaps more visible.

The next step is to make those crosswalks portable, versioned, and machine-readable.

OLIR can provide existing mapping knowledge, publication governance, and a route for contributing new NIST-oriented mappings. The OSCAL Control Mapping Model can turn those relationships into structured objects that compliance tools can validate, query, extend, and connect to broader assessment workflows.

At Secani, we see OSCAL as the canonical technical foundation. OLIR is not a competing model, but a valuable source that can enrich it.

The long-term opportunity is larger than displaying that two controls overlap. It is to create a trusted mapping layer that shows what can be reused, what remains uncovered, why a relationship exists, who approved it, and how a framework update affects the rest of the compliance program.

That is how cross-mapping moves from a collection of spreadsheets to reusable compliance infrastructure.