Secure Controls Framework
Download The SCF
SCF COREFAQAboutContact
GRC Fundamentals

Word Crime: Inheritance vs Reciprocity

In GRC operations, words have specific meanings. The concept of inheritance vs reciprocity is a common “word crimes” incident, since the terms are not interchangeable. Getting these wrong leads to incorrect control scoping, audit findings, and misplaced reliance on third-party certifications.

Learn More About GRC
Authoritative Definitions

Inheritance & Control Inheritance

Both terms are defined by NIST and have specific, distinct meanings in the context of cybersecurity control scoping. Understanding them is essential for correctly scoping assessments and audits.

Inheritance

NIST Glossary: Inheritance

A situation in which an information system or application receives protection from security controls (or portions of security controls) that are developed, implemented, and assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides.

You can also view the definition here: https://csrc.nist.gov/glossary/term/inheritance

Control Inheritance

NIST Glossary: Control Inheritance

A situation in which a system or application receives protection from security or privacy controls (or portions of controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See common control.

You can also view the definition here: https://csrc.nist.gov/glossary/term/control_inheritance

Reciprocity

NIST Glossary: Reciprocity

Mutual agreement among participating organizations to accept each other’s security assessments in order to reuse information system resources and/or to accept each other’s assessed security posture in order to share information.

You can also view the definition here: https://csrc.nist.gov/glossary/term/reciprocity

Understanding The Difference

Inheritance vs Reciprocity: How Each Works in Practice

While both concepts involve one party accepting or relying on another party’s security controls or assessments, they operate through fundamentally different mechanisms and relationships.

Inheritance

Applies when an organization has a contract in place with an External Service Provider (ESP). Certain controls that the ESP manages can be inherited by an organization using its services.

Example

The ESP's physical security practices at the ESP's data center, which the ESP controls, would be inherited by its clients. The client does not need to independently implement or assess those physical controls; they flow down from the ESP. This is common in cloud environments: an IaaS provider may provide inherited physical, environmental, and infrastructure controls, while the client retains responsibility for application-layer controls.

Reciprocity

Applies when an organization holds a certification (e.g., ISO 27001, CMMC L2, SOC 2, etc.) and wants to apply that certification as evidence of controls being met to minimize control scoping in a separate assessment or relationship.

Example: SCF CAP

The Secure Controls Framework Conformity Assessment Program (SCF CAP) offers reciprocity to organizations with a current CMMC L2 certification. Those in-scope controls would be removed from the scope of controls to be evaluated as part of a SCF CAP assessment, due to the reciprocity agreement in place for the SCF CAP to accept CMMC L2 assessments.

The Key Distinction

Inheritance is about receiving controls from a service provider through a contractual relationship where the controls flow from the ESP to the client based on the services delivered. Reciprocity is about mutual recognition of assessments between peer organizations, and this is where two organizations agreeing to accept each other’s security posture rather than conducting duplicative assessments. One is a service relationship; the other is a peer agreement.

Scoping Implications

Why Getting This Right Matters for Assessments

Incorrectly applying inheritance or reciprocity during control scoping is one of the most common sources of assessment errors, in both directions.

Over-claiming inheritance (asserting that controls are inherited when no contractual basis or formal agreement exists) results in control gaps that assessors will flag as deficiencies. An organization cannot simply declare that it inherits a cloud provider’s controls without a formal documentation mechanism (e.g., a Shared Responsibility Matrix, or the provider’s formally documented inherited control list).

Over-claiming reciprocity (asserting that a certification removes controls from scope without a formal reciprocity agreement with the assessing body) similarly creates scope disputes and potential assessment failures. Reciprocity must be explicitly established between the certification framework and the program being assessed. It is not an automatic right of any certification holder.

Properly scoped assessments that correctly account for inherited controls and documented reciprocity agreements result in more efficient assessments, less duplicative evidence collection, and a cleaner audit record.

For Inheritance to Apply
  • A contractual relationship with the ESP must exist.
  • The ESP must formally document which controls it manages on behalf of clients.
  • The client must document the inherited controls in its SSP or equivalent scoping artifact.
  • The ESP’s authorization or certification of those controls must be current and in scope.
For Reciprocity to Apply
  • A formal reciprocity agreement must exist between the certification program and the assessing framework.
  • The organization’s certification must be current and in-scope for the relevant controls.
  • The assessing body must explicitly recognize the certification under its reciprocity program.
  • The organization must document the reciprocity claim and the certification evidence.