Audit Management

Audit Management gives you a single place to prepare for security and compliance audits: gather the evidence that demonstrates a control is met, track the findings that come out of an assessment, and drive each finding through to closure. Evidence and findings are organized around the same framework controls you track elsewhere in Compliance, so the work you do day to day feeds directly into audit readiness.

Beta capability

Compliance — including Audit Management — is a Beta capability in Cert-IX and is still expanding. The evidence organization, finding lifecycle, and remediation workflow described below are the core of what ships today. Sections marked rolling out describe automation that is planned or being introduced; treat them as roadmap rather than guaranteed behavior.

How audit management fits together

An audit, at its simplest, is a check that your controls are in place and that you can prove it. Cert-IX supports that in three linked stages:

Stage	What you do	What the platform tracks
Evidence	Collect and attach the artifacts that show each control is satisfied	Evidence items linked to the controls they support
Findings	Record gaps, observations, and non-conformities raised during (or before) an audit	Findings with severity, owner, and status
Remediation	Fix the underlying issue and prove the fix	Remediation progress until each finding is closed

Because evidence and findings attach to controls from the frameworks you already track — NIST CSF, ISO 27001, SOC 2, CIS Controls, NIS2, and any custom frameworks you define — the same record can serve more than one audit when those frameworks share overlapping requirements.

Preparing for an audit

Preparation is mostly about closing the gap between the control status you claim and the evidence you can produce. A practical sequence:

1. Confirm scope. Decide which framework(s) and which controls the audit will cover.
2. Review control status. Identify controls that are marked satisfied but have thin or missing evidence.
3. Collect evidence for those controls (see below).
4. Self-assess and note gaps. Where a control is not yet met, record it as a finding so it is tracked rather than forgotten.
5. Remediate the most significant gaps before the audit begins.

astuce

Treat gaps you find during self-assessment as first-class findings. Logging them up front means they move through the same remediation workflow as auditor-raised findings, with an owner and a clear status — instead of living in a spreadsheet.

Managing evidence

Evidence is any artifact that demonstrates a control is operating: a written policy, a configuration export, a screenshot of a setting, a ticket showing a process was followed, or output from a security scan. In Cert-IX, evidence items are attached to the controls they support, so an auditor (or a future you) can move from a control to the proof behind it directly.

Types of evidence

• Documents — policies, procedures, and standards you maintain in Policy Management.
• Configuration and screenshots — exported settings or captured screens that show a control is configured correctly.
• Scan output — findings and results produced by Cert-IX's own vulnerability scanning. Because the platform already runs dependency and vulnerability scans (see Vulnerability Management), scan results can serve as evidence that technical controls are being monitored.
• Records and tickets — artifacts that show a recurring process (access reviews, patching, incident handling) actually happened.

Each evidence item records who added it and when, so you retain a basic history of what was submitted for a given control.

remarque

Automated evidence collection — pulling evidence for certain technical controls directly from platform data on a schedule — is rolling out. Today, plan to attach most evidence manually or export it from the relevant Cert-IX surface.

Tracking findings

A finding is anything an audit surfaces that needs attention: a missing control, a partially met requirement, or an observation for improvement. Findings are the unit of work you manage after (and during) an assessment.

What a finding records

Field	Purpose
Description	What the issue is and why it matters
Severity	How serious the gap is (Critical / High / Medium / Low)
Affected control(s)	The framework requirement(s) the finding relates to
Owner	The person accountable for remediation
Remediation notes	The plan and the evidence needed to prove the fix

Finding lifecycle

Findings move through a defined set of states so their status is unambiguous at any point:

• Open — the finding has been recorded but work has not started.
• In Progress — remediation is underway.
• Pending Verification — a fix has been implemented and is awaiting confirmation.
• Closed — the fix has been verified and the finding is resolved.
• Risk Accepted — the organization has consciously chosen to accept the risk, with that decision documented rather than remediated.

The typical path is Open → In Progress → Pending Verification → Closed, with Risk Accepted available when remediation is not the chosen response. Separating Pending Verification from Closed keeps a fix from being marked done until someone has confirmed it actually worked.

Remediation workflow

1. Log the finding with a description, severity, and affected control(s).
2. Assign an owner who is accountable for resolving it.
3. Plan the remediation and note what evidence will prove the fix.
4. Implement the change.
5. Gather evidence and attach it to the finding and the related control.
6. Verify that the change had the intended effect.
7. Close the finding — or record a documented Risk Accepted decision.

Where a finding stems from a technical vulnerability, the same issue is often already tracked in Vulnerability Management; linking the two keeps the audit view and the operational view consistent.

During and after the audit

• During the audit, respond to auditor requests by pointing to (or exporting) the evidence attached to each control, and log any issues the auditor raises as findings so they enter the remediation workflow immediately.
• After the audit, review each finding, confirm it is accurate, assign owners, and prioritize remediation by severity. Findings then follow the lifecycle above until every item reaches Closed or a documented Risk Accepted state.

Staying audit-ready between assessments

Audit readiness is easier to maintain than to recreate. Rather than treating each audit as a one-off scramble, keep evidence attached to controls as your environment changes and resolve findings as they arise, so the gap between "compliant on paper" and "provable today" stays small.

Rolling out

Deeper automation — continuous control monitoring, scheduled evidence refresh, and configuration drift detection — is planned for Compliance as it matures out of Beta. Until then, ongoing readiness is primarily a matter of keeping evidence current and working findings to closure.

Exporting audit information

You can export the evidence and findings associated with an audit to share with auditors or retain for your records — for example, the list of findings and their current status, or the evidence attached to a set of controls. This gives you a portable snapshot of where a framework stands without needing to grant direct platform access.

---

Next steps

• Compliance Overview — how frameworks, policies, and audit support fit together.
• Frameworks — the frameworks you can track and map controls against.
• Compliance Matrix — see control coverage across frameworks in one view.
• Vulnerability Management — where technical findings that often become audit evidence originate.