Controls

Use this when…

• you need a clean, defensible control baseline for an audit/certification (SOC 2 / ISO 27001 are common examples)
• customer questionnaires ask “do you have X?” and you need consistent answers
• your evidence is messy because it’s not tied to a specific control

Recommended workflow

1. Review the control set and remove/disable anything you won’t operate.
2. For each critical control:
   • assign an owner
   • define cadence (continuous/monthly/quarterly)
   • confirm an evidence path (automated if possible)
3. Treat control language as a contract with yourself: if you write it, you should be able to operate it.

What the directory shows

The /controls directory can be searched and filtered by framework, framework reference, status, domain, and owner. Each row shows the control ID, name, domain, framework mappings, status, owner, evidence coverage, and last update. Bulk actions can move selected controls to implemented, in progress, pending review, or not applicable where the transition is permitted.

Coverage represents the control's expected evidence items that are satisfied. A control cannot be marked implemented until it has complete coverage. Coverage is a completeness signal, not a conclusion that the evidence is accurate, representative, or sufficient for an auditor.

Control detail (/controls/[id])

Use the detail page to understand and operate one control:

• Control details: description, guidance, domain, framework references, and implementation context.
• Properties: owner, status, and last update.
• Evidence: linked automated evidence, manual uploads, policies, and requirement-level mappings.
• Notes: implementation decisions, exceptions, and reviewer context.

When linking evidence, choose the specific requirement it satisfies when possible. “Control only” is available when the artifact supports the control generally but no individual evidence requirement.

Status guidance

• In progress: the control is being designed or implemented.
• Pending review: implementation is ready for independent review.
• Implemented: expected evidence coverage is complete and the control is operating.
• Not applicable: scope or risk analysis supports exclusion; retain the rationale.
• Archived: the control is no longer part of the active baseline.

Never use status as a substitute for an implementation narrative or proof. Reviewers need to understand who performs the control, how often, in which systems, and what evidence the activity leaves behind.

How it supports compliance

Controls are reusable across frameworks. As concrete examples:

• SOC 2: controls support both design and operating effectiveness narratives.
• ISO 27001: controls align to Annex A and your ISMS processes.
• GDPR: security controls (access, logging, encryption, vendor mgmt) support integrity/confidentiality obligations.

For ISO 27001 work, the control export can produce a Statement of Applicability-oriented CSV; other framework selections can be exported to a workbook. Verify scope, applicability, and justification before using an export in an audit.