Frameworks & Controls

zGovern ships with 292 pre-built controls across five major compliance frameworks. 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

Framework Controls Use Case Issued By
SOC 2 Type II 63 SaaS security audits — required by most enterprise customers AICPA
ISO 27001:2022 94 International information security management system (ISMS) ISO / IEC
GDPR 51 EU personal data protection — required if you process EU resident data European Commission
HIPAA 58 US healthcare data — required for covered entities and business associates HHS / OCR
India DPDP Act 2023 26 Indian personal data protection — required for data fiduciaries in India MeitY, Government of India
Total 292
💡
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 framework before you finish 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.