Governance pack generation

[mrmez]

Overview

Extend AuditKit beyond technical scanning to generate complete governance documentation (policies, standards, procedures) that maps directly to technical controls and evidence, eliminating "Excel merge week" during audits.

Problem Statement

As highlighted by community feedback from an ex-auditor:

"Auditors don't just ask 'did you scan?', they ask 'show me the policy, the standard, the procedure, and the evidence that it's enforced.' Right now that lives in a mess of Google Docs, Confluence, and screenshots."

Technical compliance scanning is only 30% of audit prep. The other 70% is documentation that proves:

1. You have policies defining security requirements
2. You have standards implementing those policies
3. You have procedures showing how to execute
4. Your technical controls actually enforce the above

Proposed Solution

Phase 1: Control Mapping Layer (Priority: HIGH - v0.7.0)

• Create bidirectional mapping: Technical checks ↔ Compliance requirements ↔ Policy sections
• Generate control traceability matrix
• Link evidence to specific policy requirements

Example:

# /mappings/soc2_cc6_3.yaml
control: CC6.3
name: "Encryption at Rest"
description: "The entity encrypts data at rest"

technical_checks:
  - aws.s3.encryption
  - azure.storage.encryption  
  - scubagear.MS.SHAREPOINT.1.2

policy_requirements:
  - "All data at rest must be encrypted using AES-256 or stronger"
  - "Encryption keys must be rotated annually"
  - "Key management must follow principle of least privilege"

evidence_required:
  - screenshot: "S3 bucket encryption settings"
  - screenshot: "KMS key rotation configuration"
  - document: "Key management procedure"

Phase 2: Policy Generation (Priority: MEDIUM - v0.8.0)

• Policy templates with organization-specific placeholders
• Standards documents with technical specifications
• Procedure documents with step-by-step instructions
• Auto-populate from scan results where possible

Example usage:

# Initialize governance docs for your stack
auditkit docs init \
  --framework soc2 \
  --providers aws,azure \
  --integrations scubagear \
  --org "Acme Corp" \
  --data-retention 90 \
  --key-rotation 365

# Generate complete audit package
auditkit report --unified --include-governance --output audit-package/

Phase 3: Complete Audit Binder (Priority: LOW - Future)

• Management assertions
• System descriptions
• CUEC (Complementary User Entity Controls)
• Risk assessment templates
• Evidence index with checksums

Technical Implementation

Architecture

/docpacks/
├── base/                          # Framework-agnostic templates
│   ├── policies/
│   │   ├── information_security.md
│   │   ├── access_control.md
│   │   ├── encryption.md
│   │   ├── logging_monitoring.md
│   │   ├── incident_response.md
│   │   ├── change_management.md
│   │   ├── vendor_risk.md
│   │   └── bcdr.md
│   ├── standards/
│   │   ├── technical_standards.yaml
│   │   └── operational_standards.yaml
│   └── procedures/
│       └── evidence_collection.md
├── soc2/                          # SOC2-specific additions
│   ├── control_matrix.yaml
│   └── cuecs.md
├── pci/                           # PCI-specific requirements
│   ├── control_matrix.yaml
│   └── network_diagram_template.md
└── iso27001/                      # ISO-specific
    └── statement_of_applicability.md

/pkg/governance/
├── generator.go                  # Document generation engine
├── mapper.go                      # Control↔Policy↔Evidence mapping
├── templates.go                   # Template processing
└── variables.go                   # Organization variables

Policy Template Example

<!-- /docpacks/base/policies/encryption.md -->
# {{ORG_NAME}} Encryption Policy

**Document ID:** POL-SEC-003  
**Version:** {{VERSION}}  
**Effective Date:** {{EFFECTIVE_DATE}}  
**Owner:** {{CISO_NAME}}  
**Classification:** {{CLASSIFICATION}}

## 1. Purpose
This policy establishes requirements for protecting {{ORG_NAME}} information through encryption.

## 2. Scope
This policy applies to all {{ORG_NAME}} systems processing {{DATA_CLASSIFICATIONS}}.

## 3. Policy Statements

### 3.1 Encryption at Rest
- All {{SENSITIVE_DATA_TYPES}} MUST be encrypted at rest
- Minimum encryption standard: {{MIN_ENCRYPTION_STANDARD}}
- Key length: {{MIN_KEY_LENGTH}} bits minimum

**Technical Implementation:** {{LINK:aws.s3.encryption,azure.storage.encryption}}  
**Last Validated:** {{LAST_SCAN_DATE}}  
**Compliance Status:** {{COMPLIANCE_STATUS:CC6.3}}

### 3.2 Encryption in Transit
- All data transmission MUST use TLS {{MIN_TLS_VERSION}} or higher
- Deprecated protocols (SSL, TLS 1.0, TLS 1.1) are PROHIBITED

**Technical Implementation:** {{LINK:aws.elb.tls,azure.appgw.ssl}}  
**Last Validated:** {{LAST_SCAN_DATE}}  
**Compliance Status:** {{COMPLIANCE_STATUS:CC6.3}}

### 3.3 Key Management
- Encryption keys MUST be rotated every {{KEY_ROTATION_DAYS}} days
- Key material MUST NOT be stored with encrypted data
- Keys MUST be managed using {{KMS_SOLUTION}}

## 4. Compliance Mapping
- SOC2: CC6.3, CC6.7
- PCI-DSS: 3.4, 3.4.1, 4.1
- ISO 27001: A.10.1

## 5. Exceptions
Exceptions must be approved by {{APPROVAL_ROLE}} and documented in {{GRC_SYSTEM}}.

## 6. Enforcement
Non-compliance will be automatically detected via AuditKit scans and reported to {{SECURITY_TEAM}}.

Variables Configuration

# /templates/variables.yaml
organization:
  ORG_NAME: "Acme Corp"
  CISO_NAME: "Jane Smith"
  SECURITY_TEAM: "security@acme.com"

technical:
  MIN_ENCRYPTION_STANDARD: "AES-256"
  MIN_KEY_LENGTH: 256
  MIN_TLS_VERSION: "1.2"
  KEY_ROTATION_DAYS: 365
  KMS_SOLUTION: "AWS KMS"

compliance:
  DATA_CLASSIFICATIONS: ["PII", "PCI", "Confidential"]
  SENSITIVE_DATA_TYPES: ["customer data", "payment information", "employee records"]

systems:
  GRC_SYSTEM: "ServiceNow GRC"
  APPROVAL_ROLE: "Chief Information Security Officer"

Success Criteria

• Generate policy documents that reference actual technical controls
• Technical scan results auto-populate compliance status in policies
• Control matrix maps every check to framework requirements
• Evidence collection links to specific policy sections
• Reduce audit prep time by 70%

Acceptance Testing

1. Document Generation

   • Generate full policy set for SOC2
   • Variables properly replaced
   • Technical controls linked correctly

2. Mapping Accuracy

   • Every technical check maps to policy section
   • Every policy requirement has technical validation
   • Evidence requirements clearly defined

3. Auditor Review

   • Get feedback from actual auditors
   • Validate against real audit requirements
   • Ensure format matches expectations

Risk Considerations

⚠️ Legal Disclaimer Required

• Templates are examples only
• Organizations must review and customize
• Not legal advice
• No guarantee of compliance

Community Contribution

Looking for help with:

• Policy template contributions
• Control mapping validation
• Auditor feedback on format
• Industry-specific requirements (HIPAA, FedRAMP)

Monetization Potential

• Free Tier: Basic templates, community-maintained
• Pro Tier: Industry-specific templates, quarterly updates
• Enterprise: Custom templates, audit support

Related Issues

• #[TBD] - ScubaGear integration
• #[TBD] - Plugin architecture
• #[TBD] - Evidence orchestration

---

Labels: enhancement, documentation, help-wanted
Milestone: v0.8.0 (Phase 2)

[mrmoon0986]

Here is an example of how this part could be structured at a basic level.

This is just an initial draft example to illustrate the direction, the complete content will require additional effort from my side to prepare templates across multiple tiers (policies, standards, procedures, evidence) to make it unified and audit-ready.

Baseline Folder: encryption/

auditkit-governance/
└── encryption/
    ├── mappings/
    │   └── soc2_cc6_3.yaml
    ├── policies/
    │   └── encryption_policy.md
    ├── standards/
    │   └── encryption_standard.yaml
    ├── procedures/
    │   └── key_management_procedure.md
    └── evidence/
        └── evidence_index.md

/mappings/soc2_cc6_3.yaml

SOC 2 CC6.3 Mapping: Encryption at Rest

control: CC6.3
framework: SOC2
title: "Encryption at Rest"
description: >
  The entity encrypts data at rest to protect the confidentiality and integrity
  of information stored on systems and media.

policy_requirements:
  - "All data classified as Confidential or higher must be encrypted at rest."
  - "Keys must be rotated annually and stored in an approved Key Management Service (KMS)."
  - "Encryption configurations must be reviewed quarterly."

standards:
  - "AES-256 encryption or stronger must be used for data at rest."
  - "TLS 1.2 or higher must be used for data in transit."
  - "Key access must follow the principle of least privilege."

procedures:
  - "Verify encryption settings for all cloud and local storage systems."
  - "Confirm key rotation configurations within KMS."
  - "Review encryption configurations for compliance quarterly."

evidence_required:
  - "Screenshot: S3 bucket encryption settings"
  - "Document: Key rotation SOP"
  - "Report: AuditKit scan results for aws.s3.encryption"

cross_mappings:
  ISO27001: A.10.1
  PCI-DSS: 3.4
  HIPAA: 164.312(a)(2)(iv)

tags: ["encryption", "data-protection", "key-management"]
criticality: HIGH

/policies/encryption_policy.md

# {{ORG_NAME}} Encryption Policy

**Document ID:** POL-SEC-003  
**Version:** {{VERSION}}  
**Effective Date:** {{EFFECTIVE_DATE}}  
**Owner:** {{CISO_NAME}}  
**Classification:** Internal  

---

## 1. Purpose
To protect {{ORG_NAME}} information assets by ensuring that all sensitive data
is encrypted both at rest and in transit, using approved cryptographic methods.

## 2. Scope
Applies to all systems, applications, and storage managed by {{ORG_NAME}},
including cloud and on-premises environments.

## 3. Policy Statements

### 3.1 Encryption at Rest
- All {{SENSITIVE_DATA_TYPES}} must be encrypted using {{MIN_ENCRYPTION_STANDARD}}.
- Keys must be rotated every {{KEY_ROTATION_DAYS}} days.
- Key material must never be stored with encrypted data.

### 3.2 Encryption in Transit
- All network communications must use TLS {{MIN_TLS_VERSION}} or higher.
- Deprecated protocols (SSL, TLS 1.0, TLS 1.1) are prohibited.

### 3.3 Key Management
- All encryption keys must be managed using {{KMS_SOLUTION}}.
- Key access must follow the principle of least privilege.
- Access logs must be reviewed quarterly.

## 4. Compliance Mapping
- SOC 2: CC6.3  
- ISO 27001: A.10.1  
- PCI DSS: 3.4  
- HIPAA: §164.312(a)(2)(iv)

## 5. Enforcement
Violations of this policy will be investigated and remediated within
{{REMEDIATION_DAYS}} days. Exceptions must be approved by {{APPROVAL_ROLE}}.

---

/standards/encryption_standard.yaml

# Encryption Standards

encryption:
  algorithms:
    - AES-256
    - RSA-2048
  minimum_key_length_bits: 256
  tls_minimum_version: "1.2"
  kms_required: true
  key_rotation_days: 365
  kms_solution: "AWS KMS"
  logging_enabled: true
  review_frequency: "quarterly"

documentation:
  reviewed_by: "Security Team"
  review_method: "Automated AuditKit Scan + Manual Review"
  version: "1.0"

/procedures/key_management_procedure.md

# Key Management Procedure

## 1. Purpose
Define how {{ORG_NAME}} manages encryption keys to ensure secure storage,
rotation, and usage throughout their lifecycle.

## 2. Responsibilities
- **Security Team:** Maintain KMS configuration and review key access logs.
- **System Owners:** Ensure all data storage uses approved KMS-managed keys.
- **CISO:** Approve key lifecycle procedures and exceptions.

## 3. Procedure
1. Generate encryption keys using {{KMS_SOLUTION}}.
2. Assign administrators based on least privilege.
3. Configure automatic key rotation every {{KEY_ROTATION_DAYS}} days.
4. Monitor access via KMS logs and CloudTrail.
5. Review and document access quarterly.
6. Revoke keys immediately if compromise is suspected.

## 4. References
- Encryption Policy (POL-SEC-003)
- Encryption Standard (STD-SEC-003)

/evidence/evidence_index.md

Evidence Index — Encryption & Key Management

Evidence Type	Description	Source	Review Frequency
Screenshot	AWS S3 encryption configuration	AWS Console	Quarterly
Document	Key Management SOP	Confluence	Annual
Log	KMS access log export	CloudTrail	Quarterly
Report	AuditKit scan output	auditkit CLI	Continuous

---

All evidence must be stored in {{EVIDENCE_REPOSITORY}} and linked to the corresponding control ID (CC6.3, A.10.1, PCI 3.4).

@mrmez please share your thoughts, e.g., what would facilitate your development process?

[mrmez]

@mrmoon0986 thanks for putting this together - really appreciate the detailed example. This helps a lot to see how you're thinking about the structure.

The good news: The hierarchy you've laid out (mappings -> policies -> standards -> procedures -> evidence) makes total sense. That's exactly how auditors think about this stuff - they want to trace from "here's our policy" down to "here's proof we actually do it."

The reality check: I just shipped v0.7.0 with GCP support, and honestly? I need to figure out if governance document generation is what people actually want, or if I'm solving a problem that doesn't exist yet.

Here's where I'm at:

The technical scanning works. AuditKit can tell you what's misconfigured in your cloud environment - that part is solid. The question is whether people need auto-generated policy documents, or if they're fine just getting the scan results and handling the paperwork themselves.

Your example shows the full vision - templates with variables like {{ORG_NAME}} and {{KEY_ROTATION_DAYS}}, linking to technical checks, auto-populating compliance status. That's powerful, but it's also complex as hell. And I'm not sure yet if it's solving a $300/month problem or a "nice to have" problem.

The evidence orchestration piece is what really makes me pause. You've got:

**Evidence Required:**
- Screenshot: S3 bucket encryption settings
- Document: Key rotation SOP  
- Report: AuditKit scan results

So... how automated should this be? Do people want a checklist that says "go take these 3 screenshots" (way simpler), or do they want actual automation that runs the scan, captures the screenshots, organizes everything (way more complex)?

I honestly don't know yet, and I'm hesitant to build something elaborate before I know there's real demand.

Here's what I'm thinking:

Maybe start with just the control mapping piece - the YAML files that connect technical checks to framework requirements. That's useful on its own and doesn't commit me to building a full document generation engine. Then see if people actually ask for the policy templates.

But I also want to ask you directly: are you preparing for an actual audit right now? If so, what's the bigger pain point - getting the technical scanning done, or generating all the policy documentation? I suspect its the latter based on our previous discussions, but either way, this back and forth is good for fidelity. With that said, your answer would help me figure out if this belongs in v0.8.0 or if it's more of a "someday" feature.

And if you (or anyone else) wants to contribute policy templates, I'm definitely open to that. Scanning code is my thing - policy writing, not so much.

[mrmoon0986]

@mrmez Thanks for your reply, I really appreciate your reality-check approach. That kind of thinking is usually missing, not only in compliance tooling, but in most projects people do 🙂.

From my experience (both auditing and being audited), I don’t think most teams actually need a document generator. What auditors usually care about is whether a policy or procedure has been reviewed within the last year. If it’s current, they move on, they rarely read every line.

What does matter is traceability: a clear link between policy → standard → procedure → control → evidence. That chain gives internal assurance and helps during audits, even if the documents themselves stay mostly static.

Procedures and guidelines are inherently manual and full of technical detail, so automation there doesn’t add much value. I fully agree with your line, “That’s powerful, but complex as hell.” Even if it’s powerful, the practical payoff isn’t obvious right now.

For me, audit readiness is a continual process, and honestly, the biggest pain point isn’t scanning or document generation, it’s the decline in auditor technical literacy. I often end up explaining basics (like the difference between a User and a Login in SQL Server).

So I’d see governance document generation as a “nice to have” rather than a priority.

What could be genuinely useful, though, is an intelligence layer that tracks new or upcoming regulations and flags what might affect the organization, e.g., DORA in the EU or CMMC Level 2 for DoD contractors.

The idea: a few diagnostic questions to determine applicability and list expected artifacts (policies, risk assessments, SSPs, etc.). That kind of “what changed and does it affect me?” capability would solve a real pain point.

In short, I’d keep the governance hierarchy as a foundation for consistency but focus near-term on control mapping and regulatory-change awareness, not full document automation.

[mrmez]

@mrmoon0986 Yeah, this is really clarifying. The traceability chain (policy -> standard -> procedure -> control -> evidence) is way simpler than full document generation, and it's actually what matters.

Here's what I'm thinking based on your feedback:

Near-term (v0.7.x):

• Add control mapping that shows the traceability chain
• Enhance the evidence packages to include artifact checklists ("AuditKit provides [technical scans], you still need [SSP, IR plan, etc.]")
• Maybe add a simple applicability guide in the docs ("Do you need CMMC? Here's how to tell")

Medium-term (v0.8.0):

• Build a ./auditkit assess-applicability command that asks diagnostic questions and tells you which frameworks apply + deadlines
• Track framework changes ("ISO 27001:2022 has 93 controls vs 114 in 2013, here's what's new")

The regulatory intelligence layer makes sense, especially for time-sensitive stuff like CMMC Level 2 (Nov 2025 deadline). That's concrete and useful. The challenge is keeping regulatory data current... that's ongoing maintenance, not a one-time build. But for defense contractors hitting the CMMC deadline, it's worth it since it's a known market with urgency.

Your point about declining auditor technical literacy is unfortunate, but rings true. I've had to explain the difference between Data at rest encryption vs in transit to people who should know better. Not sure we can solve that problem, but at least AuditKit can provide technically accurate evidence.

Thanks again for the reality check. This is way more useful than me building a templating engine nobody asked for. I am going to leave this open until we come to a resolution. Thanks again.

[auditkit-admin]

Just wanted to add an update here. I've pushed a new update, but this particular one is still being worked. Keeping open for now, thanks!