Passa al contenuto principale
Versione: Next 🚧

Compliance Frameworks

Cert-IX Compliance lets you track your security program against recognized frameworks. Each framework is represented as a structured set of controls; you record where you stand on every control, attach supporting evidence, surface the gaps, and see a rolled-up view of how far along a framework is. Because most organizations answer to more than one standard, controls can be mapped across frameworks so overlapping requirements share the same status and evidence.

Beta capability

Compliance framework tracking is a Beta feature and is actively evolving. Available frameworks, control content, and mapping behavior may change between releases. Use it to organize and evidence your program — not as a substitute for a formal certification audit.

How framework tracking works

A framework in Cert-IX is a hierarchy of controls — the individual requirements a standard expects you to meet — grouped the way that standard organizes them (for example, ISO 27001 groups controls into themes, while NIST CSF groups them into Functions). Working through a framework follows a consistent pattern:

  1. Add the framework to your workspace, either from the built-in library or as a custom definition.
  2. Set the scope — the systems, teams, and locations the framework applies to — so control status reflects only what's in scope.
  3. Assess each control and record its status (see Control status).
  4. Attach evidence that demonstrates the control is in place.
  5. Track gaps where controls are partial or missing, and follow them through remediation.

The result is a per-framework completion view built from the status of its controls, rather than a single hand-entered number. Findings from other parts of the platform can inform your assessment: vulnerability results from Vulnerability Management speak to technical controls, and the Bitenforcer scanner agent's CIS, STIG, and PCI-DSS hardening checks provide concrete evidence for configuration-related controls. See Scanner Agents for how those checks run.

Built-in frameworks

The following frameworks are available in the Cert-IX library. Anything not listed here can still be tracked as a custom framework.

FrameworkHow it's organizedWhat it covers
NIST CSFFunctions → Categories → SubcategoriesOutcome-based cybersecurity risk management
ISO/IEC 27001:202293 Annex A controls across 4 themesInformation security management system (ISMS)
SOC 25 Trust Services CriteriaService-provider security and privacy commitments
CIS Controls18 controls, grouped by Implementation GroupPrioritized, prescriptive security safeguards
NIS2Risk-management measures and reporting dutiesEU baseline for essential and important entities

NIST Cybersecurity Framework (CSF)

The NIST CSF describes cybersecurity outcomes organized into Functions — Identify, Protect, Detect, Respond, and Recover, with Govern added in CSF 2.0. Each Function breaks down into Categories and Subcategories, which map naturally onto trackable controls. Because CSF is outcome-based rather than prescriptive, it works well as a top-level view of program maturity.

ISO/IEC 27001

ISO/IEC 27001 is the international standard for an information security management system. The current 2022 revision defines 93 Annex A controls organized into four themes:

  • Organizational controls
  • People controls
  • Physical controls
  • Technological controls
note

Earlier documentation and older tooling often cite "114 controls across 14 domains." That structure belongs to the withdrawn 2013 edition. Cert-IX tracks the current 2022 revision (93 controls, 4 themes).

SOC 2

SOC 2 is built on the AICPA Trust Services Criteria. The Security criterion (the Common Criteria) is mandatory; the remaining four are included based on the commitments you make to customers:

  • Security
  • Availability
  • Processing Integrity
  • Confidentiality
  • Privacy

CIS Controls

The Center for Internet Security publishes a prioritized, prescriptive set of safeguards. Version 8 groups 18 controls into Implementation GroupsIG1, IG2, and IG3 — so smaller organizations can start with essential cyber hygiene (IG1) and layer on additional safeguards as their program matures. CIS mappings also align closely with the hardening checks the Bitenforcer agent runs.

NIS2

NIS2 (Directive (EU) 2022/2555) sets baseline cybersecurity risk-management measures and incident-reporting obligations for essential and important entities operating in the EU. Tracking it in Cert-IX helps EU-facing organizations organize the measures NIS2 expects — risk management, supply-chain security, incident handling, and reporting readiness.

Custom frameworks

When a standard isn't in the built-in library, or you need to track internal, contractual, or sector-specific obligations, create a custom framework. You define its structure and its controls, then assess, evidence, and map them exactly like a built-in framework. Common uses include:

  • Regulatory obligations such as HIPAA, PCI DSS, or GDPR requirements.
  • Customer or contractual security commitments.
  • Internal security baselines and policies.
suggerimento

If you already track a built-in framework, reuse its controls when defining a custom one and map the overlapping items — you'll avoid re-evidencing the same work. See Cross-framework mapping.

Working with controls

Control status

Every control carries a status that describes how well it's satisfied within your defined scope:

StatusMeaning
ImplementedThe control is fully in place and evidenced.
Partially ImplementedThe control is in place but has gaps.
Not ImplementedThe control is not yet in place.
Not ApplicableThe control is out of scope and excluded from rollups.

Ownership and scope

Controls can be assigned to owners so accountability is clear, and each framework's scope determines which systems, teams, and locations its controls apply to. Marking a control Not Applicable removes it from the framework's completion view rather than counting it against you.

Evidence

Evidence is what demonstrates a control is genuinely in place — documents, configuration exports, links to policies, or references to findings elsewhere in the platform. Evidence is attached to the specific control it supports, so an audit reviewer can trace each claim back to its proof. Where a control is technical, results from vulnerability scanning or agent hardening checks make strong, verifiable evidence.

Cross-framework mapping

Different standards frequently ask for the same underlying safeguard: multi-factor authentication, access reviews, encryption at rest, logging, and so on. Cross-framework mapping links controls that express the same requirement across frameworks. When controls are mapped:

  • Assessing or evidencing one mapped control reflects on the others, so the same safeguard doesn't have to be documented separately for every framework.
  • A single piece of evidence can satisfy the mapped controls together.
  • You get a consolidated picture of where one improvement moves the needle across multiple standards at once.

This is most valuable when you track several frameworks — for example, mapping ISO 27001 access-control items to their NIST CSF and CIS equivalents so overlapping work counts once.

Gaps and remediation

Anything short of Implemented — a partial control, a missing control, or a control lacking evidence — surfaces as a gap. From there you can prioritize the gaps that matter most, assign an owner, and track them through to closure. Framework completion views update as gaps are addressed, giving you a running sense of readiness rather than a point-in-time snapshot taken only at audit time.

For the audit-facing side of this workflow — findings, evidence review, and audit records — see Audit.

Best practices

  1. Start with one framework. Build the muscle of assessing and evidencing controls before adding more.
  2. Scope deliberately. Accurate scope keeps completion views honest and keeps out-of-scope systems from skewing your status.
  3. Assign owners early. Controls without an owner tend to stall.
  4. Evidence as you go. Attach evidence when a control is implemented, not the week before an audit.
  5. Map overlapping controls. Once you track more than one framework, mapping shared controls saves the most repeated effort.

  • Compliance Overview — how the Compliance area fits together.
  • Compliance Matrix — see control coverage across frameworks side by side.
  • Audit — findings, evidence review, and audit records.
  • Scanner Agents — Bitenforcer CIS/STIG/PCI-DSS hardening checks that feed control evidence.

Questa pagina ti è stata utile?