Frameworks & Controls

zGovern ships with 482 pre-built controls across 18 compliance frameworks, organised into five categories. Each control includes plain-English guidance, evidence requirements, and testing frequency — ready to use on day one.

What is a Framework?

A compliance framework is a structured set of controls (requirements) published by a standards body or regulatory authority. Organizations demonstrate compliance by satisfying every applicable control in a framework through documented evidence, policies, and processes.

zGovern lets you activate multiple frameworks simultaneously. A single piece of evidence (e.g., an MFA policy screenshot) can satisfy controls across multiple frameworks at once, eliminating duplicate work.

Supported Frameworks

Frameworks are organised into five categories. You can activate any combination simultaneously — controls and evidence are automatically shared across frameworks via cross-framework mappings.

Security

FrameworkControlsUse CaseIssued By
SOC 2 Type II 62 SaaS security audits — required by most enterprise customers AICPA
ISO 27001:2022 93 International information security management system (ISMS) ISO / IEC
PCI-DSS 4.0 13 Payment card industry data security — required if you process card data PCI SSC
NIST CSF 2.0 24 US cybersecurity framework — widely used for security program structuring NIST
NIST 800-53 Rev 5 32 US federal information system controls — required for FedRAMP / government NIST
CIS Controls v8 18 Prioritised security hygiene controls — excellent baseline for any organisation Center for Internet Security

Privacy

FrameworkControlsUse CaseIssued By
GDPR 50 EU personal data protection — required if you process EU resident data European Commission
CCPA/CPRA 18 California consumer privacy — required for businesses serving California residents California AG / CPPA
DPDP Act (India) 2023 25 Indian personal data protection — required for data fiduciaries in India MeitY, Government of India
ISO 27701:2019 (Privacy Information Management) 7 Privacy extension to ISO 27001 — demonstrates GDPR alignment ISO / IEC
LGPD (Brazil) 6 Brazilian personal data protection law — required for processing Brazilian resident data ANPD, Brazil

Industry

FrameworkControlsUse CaseIssued By
HIPAA 57 US healthcare data — required for covered entities and business associates HHS / OCR
SOC 1 Type II (SSAE 18) 39 Financial reporting controls — required for service organisations affecting customer financials AICPA

Business / Operations

FrameworkControlsUse CaseIssued By
ISO 22301 7 Business continuity management — demonstrates resilience planning ISO
ISO 9001 7 Quality management system — widely required in manufacturing and services ISO
ISO 45001 7 Occupational health and safety management ISO
ISO 14001 10 Environmental management system — supports ESG programs ISO

AI Governance

FrameworkControlsUse CaseIssued By
ISO 42001 7 AI management system — required for organisations developing or deploying AI systems ISO / IEC
Cross-framework mappings zGovern maintains 86 cross-framework mappings. When you mark a control COMPLETE in one framework, linked controls in other frameworks are automatically highlighted so you can satisfy multiple frameworks with a single piece of evidence.
💡
Which framework first? Start with SOC 2 Type II if you're a B2B SaaS company — it's the most commonly requested by enterprise buyers and has significant overlap with ISO 27001, meaning you'll be well on your way to a second certification before finishing the first.

Control Anatomy

Each control in zGovern has the following fields:

Field Type Description
code string Unique control identifier within its framework (e.g., CC6.1, A.9.1.1)
title string Short name for the control (e.g., "Logical Access Controls")
category string Control domain (e.g., "Access Control", "Cryptography", "Incident Response")
priority HIGH / MEDIUM / LOW Suggested implementation priority
plainEnglish string A plain-English explanation of what the control means and why it matters
evidenceRequirements string Specific list of documents, screenshots, or artifacts needed to satisfy this control
testingFrequency ANNUAL / QUARTERLY / MONTHLY / CONTINUOUS How often this control's evidence should be refreshed
controlStatus enum Current implementation state — see Control Statuses below
ownerId UUID The user responsible for this control
dueDate datetime Target date for achieving COMPLETE status

Example Control

Here is an example of a real control as returned by the API:

GET /api/compliance/controls/cc6-1 — response excerpt
{
  "id": "clxr8k2vp0001lg3a4b5c6d7e",
  "code": "CC6.1",
  "title": "Logical and Physical Access Controls",
  "category": "Logical Access",
  "priority": "HIGH",
  "plainEnglish": "Ensure that only authorised individuals can access systems and data. This includes user provisioning, MFA enforcement, and regular access reviews.",
  "evidenceRequirements": "1. MFA policy screenshot\n2. User access list export\n3. Access review sign-off document\n4. Termination checklist for 3 sample leavers",
  "testingFrequency": "QUARTERLY",
  "controlStatus": "IN_REVIEW",
  "dueDate": "2026-06-30T00:00:00.000Z",
  "owner": {
    "id": "clxr8k2vp0002lg3a9b1c2d3e",
    "firstName": "Sarah",
    "lastName": "Chen"
  }
}

Control Statuses

Every control moves through a defined lifecycle:

NOT_STARTED IN_REVIEW COMPLETE → (or) FAILED
Status Meaning Next Step
NOT_STARTED Control has not been addressed yet. Default state for all new controls. Assign an owner and upload initial evidence
IN_REVIEW Evidence has been uploaded and is pending auditor review or approval. Auditor reviews and approves/rejects evidence
COMPLETE All evidence has been approved and the control is fully satisfied. Maintain through the next review cycle
FAILED Control failed automated checks or evidence was rejected by the auditor. Remediate the issue and re-upload evidence

Control Ownership

Assigning an owner to each control is essential for accountability. Owners receive email notifications when:

  • An automated monitoring check linked to their control fails
  • Evidence they uploaded is rejected by an auditor
  • A control's due date is approaching (7-day and 1-day warnings)
  • A control's testing frequency window has elapsed

To assign an owner, open a control in the Audit Workspace and select a user from the Owner dropdown. Any ADMIN or AUDITOR user can be assigned as a control owner.

Bulk assignment You can bulk-assign controls to an owner using the PATCH /api/compliance/controls/:id endpoint. This is useful when onboarding a new team member or reorganising ownership after a reorg.

Evidence Checklist

Each control has an evidence checklist — a structured list of specific artifacts that must be collected and approved. Checklist items are derived from the control's evidenceRequirements field and are created automatically when you activate a framework.

Each checklist item has an approval status:

Status Description
PENDING Evidence has been uploaded but not yet reviewed
APPROVED An ADMIN or AUDITOR has approved this evidence as satisfactory
REJECTED Evidence was rejected; a rejection note explains what is needed instead

Evidence files are uploaded via the Audit Workspace. Files linked to integrations are tagged with an [Auto] prefix and highlighted in blue — these do not require manual upload.

How to Complete a Control

  1. Open the Audit Workspace

    Navigate to Audit Workspace in the sidebar and select your framework from the dropdown filter.

  2. Find the control

    Use the search box or filter by category. Click any control row to expand it.

  3. Read the plain-English description

    The Plain English tab explains exactly what this control requires in simple language, without legal jargon.

  4. Review the evidence checklist

    Each checklist item specifies a particular artifact. Check items already collected automatically by integrations — these are marked [Auto].

  5. Upload evidence files

    For each remaining checklist item, click Upload Evidence and attach the relevant file (PDF, PNG, CSV, etc.). Files are stored securely and linked to this specific control.

  6. Update the control status

    Once all evidence is uploaded, change the status to IN_REVIEW. An auditor will then review and approve or reject your evidence.

  7. Respond to rejection notes

    If evidence is rejected, you'll receive a notification with a specific note. Address the feedback and re-upload the corrected evidence.