Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Framework-Neutral Common Controls for Scalable Compliance Mapping #38

Open
austinsonger opened this issue Feb 10, 2025 · 5 comments

Comments

@austinsonger
Copy link

So I do not know how the platform will be handling this common issue, because GRC can get dry and extremely confusing at time. But I'll throw it out there even if you have something like this already.

Summary

To enhance scalability and efficiency in compliance management, we propose implementing a framework-neutral common control set that enables seamless mapping to multiple frameworks. This approach simplifies evidence artifact management and ensures that adding a new framework requires only a simple mapping to existing platform-wide common control IDs.

Problem Statement

Organizations managing multiple compliance frameworks often face inefficiencies due to duplicated efforts in control implementation, evidence collection, and audit readiness. When a new framework is introduced, teams must manually re-align their compliance programs, leading to increased complexity, operational overhead, and inconsistencies in control execution.

Proposed Solution

Implement a framework-neutral common control set, where each control is uniquely identified and mapped to multiple compliance frameworks.

This solution enables:

  • One-to-Many Framework Mapping: Each control is designed to align with requirements across frameworks (AND FOR THIS EXAMPLE: it is mapped against NIST Cybersecurity Framework v2, CIS v8, PCI DSS 4.0, SOC 2, and ISO 27001:2022).
  • Simplified Evidence Artifact Collection: Evidence artifacts remain consistent across frameworks, reducing duplication and audit preparation effort.
  • Streamlined Framework Expansion: Adding a new compliance framework requires only mapping its requirements to existing control IDs rather than creating new controls from scratch.
  • Improved Scalability and Consistency: Standardized controls enhance clarity in governance, risk, and compliance (GRC) processes.
{
  "controls": [
    {
      "Control Description": "Organization maintains an inventory of information systems, which is reconciled on a periodic basis.",
      "Frequency": "Semi-Annual",
      "Test of Design": "1. Design and document a process for maintaining an inventory of information systems for management of assets within an organization.\n2. Perform inventory reconciliation on a periodic basis.\n3. Create and maintain periodic reconciliation documentation.",
      "Theme": "Process",
      "Test of Operating Effectiveness": "1. Inspect the policy and standard to determine whether requirements for maintaining and reconciling a system of inventory for information systems are defined.\n2. Observe the inventory of system devices to determine whether the organization maintains the inventory in a system of record.\n3. Inspect periodic reconciliation documentation to determine whether reconciliation was performed.",
      "Goal": "The goal of this control is to ensure that an organization maintains an accurate and up-to-date inventory of its information systems. This inventory should be periodically reconciled to verify its accuracy, enabling effective asset management, security monitoring, and compliance with organizational policies.",
      "Control Domain": "Asset Management",
      "Policy/Standard": "Asset Management Policy",
      "Evidence Artifacts": "E-AM-01, E-AM-02, E-AM-03",
      "Control Type": "Preventive",
      "CC ID": "AM-01",
      "Mapping": "ID.AM-1, ID.AM-2, 1.1, 1.2, 6.1, A.5.9, A.8.1.1, 12.5.1, 9.5.1, CC6.1, CC6.2",
      "Control Name": "Inventory Management"
    },
    {
      "Control Description": "Organization maintains an inventory of application assets, which is reconciled on a periodic basis.",
      "Frequency": "Semi-Annual",
      "Test of Design": "1. Design and document a process for maintaining an inventory of application assets for management of assets within an organization\n2. Perform inventory reconciliation on a periodic basis.\n3. Create and maintain periodic reconciliation documentation.",
      "Theme": "Process",
      "Test of Operating Effectiveness": "1. Inspect the policy and standard to determine whether requirements for maintaining and reconciling a system of inventory for application assets are defined.\n2. Observe the inventory of system devices to determine whether the organization maintains the inventory in a system of record.\n3. Inspect periodic reconciliation documentation to determine whether reconciliation was performed.",
      "Goal": "The goal of this control is to ensure that an organization maintains an accurate and up-to-date inventory of its application assets. This inventory should be periodically reconciled to verify completeness and accuracy, supporting effective asset management, security, and compliance.",
      "Control Domain": "Asset Management",
      "Policy/Standard": "Asset Management Policy",
      "Evidence Artifacts": "E-AM-01, E-AM-02, E-AM-03",
      "Control Type": "Preventive",
      "CC ID": "AM-02",
      "Mapping": "ID.AM-2, ID.AM-5, 2.1, 2.3, 6.3, A.5.9, A.12.1.3, 12.3.3, 6.4.1, CC6.2, CC7.1",
      "Control Name": "Inventory Management: Applications"
    },
    {
      "Control Description": "Organization reconciles network discovery scans against the established device inventory on a quarterly basis; non-inventoried devices are assigned an owner.",
      "Frequency": "Quarterly",
      "Test of Design": "1. Design and document a process for conducting network discovery scans on a periodic basis.\n2. Ensure the results of the scans are reconciled with the system asset inventory at least quarterly.\n3. Ensure necessary actions are taken to include non-inventoried assets in the inventory with appropriate ownership details.",
      "Theme": "Process",
      "Test of Operating Effectiveness": "1. Inspect network discovery scans result to ensure periodic scans were conducted. \n2. Observe the reconciliation report of network discovery scans against the established device inventory to determine that the inventories are reconciled on a quarterly basis.\n3. Inspect the device inventory to ensure non-inventoried devices have been added and have a designed owner.",
      "Goal": "The goal of this control is to ensure that an organization maintains an accurate inventory of network-connected devices by reconciling network discovery scans, such as ARP table data, against the established device inventory on a quarterly basis. This process helps identify unauthorized or untracked devices and ensures they are assigned an owner for proper accountability.",
      "Control Domain": "Asset Management",
      "Policy/Standard": "Asset Management Policy",
      "Evidence Artifacts": "E-AM-04, E-AM-03\n\nE-AM-02",
      "Control Type": "Preventive",
      "CC ID": "AM-03",
      "Mapping": " ID.AM-1, PR.DS-3, DE.CM-7, 1.4, 1.5, 13.7, A.5.9, A.12.4.1, 11.1.2, 11.5.1, CC7.1, CC6.2 ",
      "Control Name": "Inventory Reconciliation: ARP Table"
    },
    {
      "Control Description": "Organization reconciles the enterprise log repository against the established device inventory on a quarterly basis; non-inventoried devices are assigned an owner.",
      "Frequency": "Semi-Annual",
      "Test of Design": "1. Ensure logs from enterprise logging solutions are reconciled with the system device asset inventory on a quarterly basis.\n\n2. Ensure necessary actions are taken to include non-inventoried assets in the inventory with appropriate ownership details",
      "Theme": "Process",
      "Test of Operating Effectiveness": "1. Inspect the reconciliation report of enterprise log repository against the established device inventory to determine that the inventories are reconciled on a quarterly basis.\n\n2. Inspect the non-inventoried devices to determine that the assets have a designed owner.",
      "Goal": "The goal of this control is to ensure that all active devices generating logs within the enterprise logging repository are accounted for in the organization's device inventory. By reconciling log data with the asset inventory on a quarterly basis, the organization can identify untracked devices and assign them an owner, ensuring accountability and compliance.",
      "Control Domain": "Asset Management",
      "Policy/Standard": "Asset Management Policy",
      "Evidence Artifacts": "E-AM-03, E-AM-02",
      "Control Type": "Preventive",
      "CC ID": "AM-04",
      "Mapping": "ID.AM-1, PR.PT-1, DE.CM-3, 8.1, 8.4, 13.5, A.5.9, A.12.4.3, 10.2.1, 11.5.1, 12.5.2, CC6.6, CC7.2",
      "Control Name": "Inventory Reconciliation: Logging"
    },
    {
      "Control Description": "Organization assets are labeled and have designated owners.",
      "Frequency": "Semi-Annual",
      "Test of Design": "1. Ensure all assets in the system device asset inventory are assigned appropriate labels as per the organization's labelling procedures.\n\n2. Ensure each asset has an assigned owner and accuracy is maintained.",
      "Theme": "Process",
      "Test of Operating Effectiveness": "1. Inspect documentation to determine whether requirements for asset labellng ownership assessment are defined.\n\n2. Inspect the asset listings to determine whether the assets are labelled and have a designated owner.\n\n3. For a sample of services, inspect the asset reports to determine asset are labelled and have a designated owner.\n\n4. Observe and compare physical assets at an organization's data center to determine whether the assets were labelled according to in-scope asset listings.",
      "Goal": "The goal of this control is to ensure that all organizational assets are properly labeled and assigned an owner to facilitate accountability, tracking, and management. Asset labeling enhances visibility, improves security, and supports compliance with asset management policies.",
      "Control Domain": "Asset Management",
      "Policy/Standard": "Asset Management Policy",
      "Evidence Artifacts": "E-AM-02, E-AM-01",
      "Control Type": "Preventive",
      "CC ID": "AM-05",
      "Mapping": "ID.AM-1, ID.AM-6, 1.3, 5.4, 6.4, A.5.9, A.8.2.2, 9.7.1, 12.5.1, CC6.1, CC6.3",
      "Control Name": "Inventory Labels"
    }
  ],
  "metadata": {
    "generated_on": "2025-02-10T22:26:05.983149",
    "title": "Common Controls",
    "description": "This document contains a structured list of common controls, including control type, control theme, evidence artifacts, and related governance policies.",
    "version": "1.0"
  }
}
@austinsonger
Copy link
Author

So this how I developed out my program at work in this fashion.

@austinsonger
Copy link
Author

Common Controls

CC_ID: "Unique CC ID"
Control_Domain: "CC Control Domain Families like asset management, change management, etc."
Control_Name: "A short control name to understand the intent of the control"
Control_Description: "Description of CC Control activity"
Control_Theme:
  - people: "Controls related to individual people"
  - process: "Controls related to processes"
  - technology: "Controls related to technology"
Control_Type: 
  - Corrective: "Corrective controls are implemented to correct any issues identified in systems or processes."
  - Detective: "Detective controls are designed to identify and detect anomalies, events, or potential incidents as they occur. "
  - Preventive: "Preventive controls aim to stop security incidents from occurring in the first place. These controls are proactive and are implemented before an event can happen to reduce the likelihood of security breaches or other incidents. "
Policy_Standard: "A recommended policy/standard which drives the control requirements within the organization"
Test_of_Design: "Evaluates whether a control has been designed to meet its intended purpose and goals. It examines the control's architecture, structure, and documented policies and procedures to ensure they are adequate for mitigating identified risks."
Test_of_Operating_Effectiveness: "Evaluates how well the control is functioning in practice. This test moves beyond just evaluating the control's design and focuses on examining whether the control is operating as intended in the real-world environment. It checks if the control is actively and effectively mitigating risks and meeting its objectives."
Evidence_Artifacts: "References to the list of evidence to support Illustrative control requirements"
Mapping:
  - SOC_2: 
      - CC6.6
      - CC7.1
  - ISO_27001_2022: 
      - A.8.16
      - A.8.17

@Marfuen
Copy link
Contributor

Marfuen commented Feb 10, 2025

Image

@austinsonger Yeah that's exactly what I'm trying to do at the moment, although my version looks different and doesn't cover everything yet.

Here's an example of a policy (subject to change of course), let me know what you think.

{
  "id": "password_policy",
  "slug": "password-policy",
  "name": "Password Policy",
  "description": "This policy outlines the requirements for passwords used by employees.",
  "template": "<html>...</html>",
  "usedBy": {
    "soc2": {
      "CC1": ["CC1.1", "CC1.2", "CC1.3"]
    }
  }
}

Then I'm writing a seed file like you are, to write it all to tables and have it be easily extensible. Similar to how you're doing I'm using ids in the json files to link to each other.

@austinsonger
Copy link
Author

austinsonger commented Feb 11, 2025

Core Entities & Their Relationships

Entity Key Relationships Description
Framework ⬌ Contain multiple Requirements Example: SOC2, NIST 800-53, ISO 27001
Requirements ⬌ Mapped to multiple Controls, Policies, and Procedures Example: "SOC2 CC6.1 - Access Control"
Controls ⬌ Linked to multiple Requirements, Policies, and Risks Example: Access Control, Incident Response
Policies ⬌ Enforce multiple Controls Defines "What" needs to be done
Procedures ⬌ Implement specific Policies & Requirements Defines "How" the policy is enforced
Risks ⬌ Linked to Controls & Threat Models Example: Data Breach Risk

1️⃣ Frameworks ⬌ Requirements (One-to-Many)

  • Each framework (e.g., SOC2, ISO 27001) contains multiple requirements.
  • Each requirement defines a specific compliance need.
{ "framework": "SOC2", "requirements": ["CC6.1 - Access Control", "CC7.2 - Incident Response"] }

2️⃣ Requirements ⬌ Controls (Many-to-Many)

  • One requirement can be mapped to multiple controls.
  • One control can fulfill multiple requirements.
{ "requirement": "SOC2 CC6.1 - Access Control", "controls": ["Identity and Access Management", "Privileged Access Management"] }

3️⃣ Requirements ⬌ Policies & Procedures (Many-to-Many)

  • Each requirement can be enforced through multiple policies.
  • Each requirement may have specific procedures for compliance.
{
  "requirement": "SOC2 CC6.1 - Access Control",
  "policies": ["Access Control Policy", "Password Policy"],
  "procedures": ["Access Request Approval Procedure", "Privileged Access Review"]
}

4️⃣ Controls ⬌ Policies (One-to-Many)

  • Each control is enforced through multiple policies.
{ "control": "Identity and Access Management", "policies": ["Password Policy", "Multi-Factor Authentication Policy"] }

5️⃣ Policies ⬌ Procedures (One-to-Many)

  • Each policy is implemented by one or more procedures.
{ "policy": "Password Policy", "procedures": ["Password Reset Procedure", "Password Expiry Process"] }

6️⃣ Controls ⬌ Risks (Many-to-Many)

  • Each control helps mitigate one or more risks.
  • Each risk can be mitigated by multiple controls.
{ "control": "Incident Response", "risks": ["Data Breach", "Ransomware Attack"] }

Outlook

data/
│── framework_requirements/
│   ├── soc2_requirements.json
│   ├── nist_800_53_requirements.json
│   ├── iso_27001_requirements.json
│   ├── cis_controls_requirements.json
│   ├── hipaa_requirements.json
│   └── pci_dss_requirements.json
│
│── controls/
│   ├── Asset_Management.json
│   ├── Backup_Management.json
│   ├── Business_Continuity.json
│   ├── Change_Management.json
│   ├── Configuration_Management.json
│   ├── Cryptography.json
│   ├── Customer_Managed_Security.json
│   ├── Data_Management.json
│   ├── Entity_Management.json
│   ├── Identity_and_Access_Management.json
│   ├── Incident_Response.json
│   ├── Mobile_Device_Management.json
│   ├── Network_Operations.json
│   ├── People_Resources.json
│   ├── Privacy.json
│   ├── Proactive_Security.json
│   ├── Risk_Management.json
│   ├── Security_Governance.json
│   ├── Service_Lifecycle.json
│   ├── Site_Operations.json
│   └── System_Design_Documentation.json
│
│── policies/
│   ├── password_policy.json
│   ├── incident_response_policy.json
│   ├── data_retention_policy.json
│   ├── access_control_policy.json
│   ├── encryption_policy.json
│   ├── vendor_management_policy.json
│   ├── acceptable_use_policy.json
│   ├── security_awareness_policy.json
│   └── disaster_recovery_policy.json
│
│── procedures/
│   ├── password_reset_procedure.json
│   ├── incident_response_playbook.json
│   ├── data_destruction_procedure.json
│   ├── employee_onboarding_procedure.json
│   ├── security_incident_reporting_procedure.json
│   ├── backup_recovery_procedure.json
│   ├── change_management_process.json
│   ├── vendor_risk_assessment_procedure.json
│   └── access_request_approval_procedure.json
│
│── mappings/
│   ├── framework_to_requirements.json
│   ├── requirements_to_controls.json
│   ├── requirements_to_policies.json
│   ├── requirements_to_procedures.json
│   ├── controls_to_policies.json
│   ├── controls_to_procedures.json
│   ├── controls_to_risks.json
│   ├── risks_to_mitigations.json
│   ├── policies_to_procedures.json
│
│── risks/
│   ├── risk_register.json
│   ├── vendor_risks.json
│
│── frameworks.json

🔥 Summary of Relationships

Entity Related Entities Type of Relationship
Frameworks Requirements One-to-Many
Requirements Controls, Policies, Procedures Many-to-Many
Controls Requirements, Policies, Risks Many-to-Many
Policies Controls, Procedures One-to-Many
Procedures Policies, Requirements One-to-Many
Risks Controls, Threat Models Many-to-Many

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants