Copy This: Your First Gemara-Based Control Mapping

Your compliance team hands you a spreadsheet with 247 controls from three different frameworks. Your job: map them to your CI/CD pipeline, container runtime, and secrets management system. The spreadsheet has columns for "Control ID," "Description," and "Owner," but nothing about where these controls actually get implemented or how they relate to each other.

This is the interoperability problem the Gemara Project solves. Described as the "OSI model for the GRC stack" with seven categorical layers, Gemara provides a structured way to think about where compliance requirements live in your infrastructure and how they connect across tools.

Purpose of the Template

This template helps you map a single compliance requirement through Gemara's seven-layer model to identify:

• Which layer of your stack implements each control
• What technical artifacts prove compliance
• Where automation can replace manual attestation
• How controls from different frameworks overlap

You'll use this for initial framework adoption, vendor evaluations, and explaining to auditors exactly where a control gets enforced.

Prerequisites

Before you fill out this template, you need:

• One specific control from your target framework (example: PCI DSS v4.0.1 Requirement 6.3.2 on inventory of bespoke software)
• Read access to your infrastructure documentation -- not the architecture diagrams gathering dust, but the actual CI/CD configs, IAM policies, and runtime settings
• A list of your current GRC tools (scanners, policy engines, ticketing systems)
• 30 minutes of uninterrupted time to trace one control end-to-end

Don't try to map your entire framework at once. Start with one control that's causing friction right now.

The Template

# Gemara Control Mapping Template
# Based on the seven-layer GRC engineering model

control_metadata:
  framework: "PCI DSS v4.0.1"
  requirement_id: "6.3.2"
  requirement_text: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
  mapped_by: "your-name"
  date: "YYYY-MM-DD"
  review_frequency: "quarterly"

# Layer 1: Policy Layer
# What does the written policy say?
policy_layer:
  policy_document: "Software Inventory Management Policy v2.1"
  policy_section: "3.4 - Component Tracking"
  human_readable_requirement: "Track all custom code and third-party dependencies"
  exceptions_defined: true
  exception_approval_process: "Security architecture review board"

# Layer 2: Control Objectives Layer  
# What outcome does this control achieve?
control_objectives:
  primary_objective: "Maintain accurate inventory for vulnerability management"
  measurable_outcome: "100% of production applications have SBOM generated and stored"
  risk_mitigated: "Unknown vulnerabilities in third-party components"
  related_controls:
    - framework: "[NIST 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)"
      control: "SA-4(6)"
      relationship: "implements same objective"

# Layer 3: Technical Controls Layer
# What actually enforces this?
technical_controls:
  - control_type: "automated"
    implementation: "Syft SBOM generator in GitHub Actions"
    enforcement_point: "CI pipeline - build stage"
    configuration_location: ".github/workflows/build.yml"
    
  - control_type: "automated"  
    implementation: "Dependency-Track for SBOM storage and analysis"
    enforcement_point: "artifact repository"
    configuration_location: "dependency-track.example.com"

# Layer 4: Evidence Collection Layer
# What proves you're doing this?
evidence_collection:
  - evidence_type: "SBOM file"
    format: "CycloneDX JSON"
    storage_location: "s3://compliance-artifacts/sboms/"
    retention_period: "3 years"
    automated: true
    
  - evidence_type: "pipeline execution logs"
    storage_location: "GitHub Actions run history"
    retention_period: "90 days"
    automated: true
    
  - evidence_type: "Dependency-Track project list"
    collection_method: "API export"
    frequency: "weekly"
    automated: true

# Layer 5: Assessment Layer
# How do you validate it's working?
assessment:
  continuous_monitoring:
    - tool: "Dependency-Track vulnerability alerts"
      frequency: "real-time"
      alert_destination: "security-team slack channel"
      
  periodic_validation:
    - method: "Sample 10 production apps, verify SBOM exists and is current"
      frequency: "quarterly"
      owner: "security engineering team"
      
  metrics_tracked:
    - "Percentage of apps with SBOM"
    - "Average time from component update to SBOM refresh"
    - "Number of components with unknown provenance"

# Layer 6: Reporting Layer
# How do you communicate compliance status?
reporting:
  internal_dashboard: "Grafana compliance dashboard - SBOM coverage panel"
  audit_report_section: "6.3.2 - Software Inventory"
  report_generation: "automated from Dependency-Track API"
  stakeholder_view: "monthly summary to engineering leadership"

# Layer 7: Governance Layer  
# Who owns this and how does it change?
governance:
  control_owner: "security-engineering-team"
  policy_owner: "ciso-office"
  escalation_path: "security team → engineering director → CISO"
  change_management: "Changes to SBOM tooling require security architecture review"
  budget_allocation: "Dependency-Track: $12k/year, Syft: open source"
  integration_dependencies:
    - "GitHub Actions must remain available"
    - "S3 bucket lifecycle policies must preserve artifacts"

How to Customize It

Start at Layer 3, not Layer 1. Most teams already have technical controls running -- they just haven't mapped them to requirements. Open your CI/CD config and look for what's already happening. Then work up to policy and down to evidence.

Fill in what you have, mark what you need. If Layer 5 (Assessment) is empty, that's your gap. Don't invent a validation process that doesn't exist -- mark it [PLANNED] and make it a backlog item.

Use the related_controls field to find overlaps. That PCI DSS requirement about software inventory? It probably also satisfies part of SOC 2 CC7.2 (system monitoring) and NIST 800-53 SA-4(6) (developer-provided training and documentation). Map those relationships explicitly. This is how Gemara addresses the interoperability problem by making cross-framework relationships visible.

Adapt the YAML structure to your tools. If you use Jira for policy management, add a jira_ticket field to the governance layer. If you store evidence in an S3 bucket with specific tagging, document that structure. The template is a starting point, not a constraint.

Be specific about automation. "Automated: true" isn't enough. Document the exact GitHub Action, the specific API endpoint, the cron schedule. Six months from now when the automation breaks, you need to know where to look.

Validation Steps

1. Trace one control end-to-end in under 10 minutes. If you can't, your mapping is too abstract. Add more specific tool names and file paths.

2. Show it to someone who didn't write it. Can they find the SBOM for your user-service app using only this document? If not, add more breadcrumbs.

3. Run a mock audit question. "Show me evidence that you maintain a software inventory." Can you pull that evidence using only the locations documented in Layer 4? Test it.

4. Check for orphaned controls. If Layer 3 (Technical Controls) is empty but Layer 1 (Policy) is full, you have a paper-only control. Mark it as a gap and prioritize implementation.

5. Validate cross-framework mappings. If you claimed this control also satisfies NIST 800-53 SA-4(6), pull up that requirement and confirm the overlap is real. Don't map aspirationally.

Start with three controls that are causing the most audit friction. Map them using this template. You'll quickly see where your gaps are and, more importantly, where you're already compliant but just haven't documented it properly. That's the dual focus of Gemara: technical integration and standardizing the compliance language you use to describe what you've built.