Policy Management

Policies are the written rules that define how your organization protects information, who is responsible for what, and how people are expected to behave. In a compliance program they play a specific role: a control is rarely considered "met" just because a technical setting is switched on — it also needs a documented, approved policy that governs it. Policies turn ad-hoc practice into something an auditor can review.

This page explains how policies relate to the frameworks and controls you track in Cert-IX, and — just as importantly — which policy features exist today versus which are still being built.

Compliance is a Beta capability

Cert-IX Compliance, including its policy support, is currently in Beta. The shipping focus today is tracking framework controls and their implementation status (see Frameworks and Audit). The richer policy-lifecycle tooling described further down this page is on the roadmap and is not all available yet. This page is deliberate about which is which.

How policies support compliance

Every framework Cert-IX helps you track expects certain topics to be governed by a formal, approved policy. The control text usually asks two things: that a rule exists in writing, and that it is actually applied. Policies are how you satisfy the first half and provide evidence for the second.

The table below shows the kinds of policy that typically back common control areas. These are standard governance topics — not templates Cert-IX ships — provided here to illustrate how policy documents map onto the controls you monitor.

Control area	Typically governed by
Access and identity	Access Control Policy, Password/Authentication Policy
Acceptable use of systems	Acceptable Use Policy
Data handling	Data Classification and Retention Policy, Privacy Policy
Incident handling	Incident Response Policy
Change and patching	Change Management Policy, Patch Management Policy
Continuity	Business Continuity and Backup Policy

When you assess a control in Cert-IX, the policy that governs it is part of the evidence trail: it records that the practice is not only enforced technically but formally owned and reviewed.

Policies and the frameworks you track

Cert-IX Compliance (Beta) is organized around frameworks. You can track control implementation across pre-loaded frameworks — NIST CSF, ISO 27001, SOC 2, CIS Controls, and NIS2 — as well as custom frameworks you define for internal standards or contractual obligations.

Because many controls across these frameworks cover the same underlying topic (access control, for example, appears in nearly all of them), a single well-written policy usually supports several controls at once. As you extend your control coverage, keep a small set of authoritative policies and reference them from each relevant control, rather than writing a new document per framework.

To see how control tracking and evidence work in practice, start with the Compliance Overview and the Frameworks guide.

Policy tooling: what's available now

Cert-IX is being honest about capability during the truth-up: several policy-management features are commonly expected in a full GRC suite, but only some are live in the current Beta. Use the table below to plan around what actually ships today.

Capability	Status
Track framework controls and implementation status	Available (Beta)
Custom frameworks for internal or contractual standards	Available (Beta)
Structured policy authoring and templates	Planned
Approval workflows for drafting and sign-off	Planned
Policy distribution and acknowledgment tracking	Planned
Version history and rollback	Planned
Exception requests and management	Planned

Roadmap items are not live

Features marked Planned — including acknowledgment tracking, reminder automation, approval routing, version rollback, and exception workflows — are not part of the current Beta. Do not build a compliance process that depends on Cert-IX performing these automatically today. Where you need them now, manage the policy lifecycle in your existing document or GRC system and track the resulting control status in Cert-IX.

Good practices for policy governance

Whether or not the tooling above is automated, the same governance discipline applies:

• Keep a single source of truth. Maintain one authoritative version of each policy and reference it from every control it supports, so an update propagates everywhere.
• Review on a schedule. Give each policy an owner and a review date. Frameworks expect evidence of periodic review, not just a document that was written once.
• Tie policies to controls. A policy that isn't linked to a control it governs is hard to defend in an assessment. Map them explicitly.
• Record exceptions deliberately. When you deviate from a policy, capture the justification, the compensating control, and an expiry date rather than leaving the gap undocumented.
• Communicate changes. Make sure the people bound by a policy know when it changes — for now, drive this through your own communication channels rather than assuming an in-platform notification.

Learn more

• Compliance Overview — how the Beta compliance capability is organized.
• Frameworks — the frameworks Cert-IX tracks and how controls map across them.
• Audit — findings, evidence, and control assessment.
• Compliance Matrix — a cross-framework view of your control coverage.