Compliance Packs
A compliance pack is a framework-scoped report. For each control defined by the framework, HarborGuard runs the control's data queries against your live data, evaluates pass/fail rules, and emits the data files an auditor expects to see.
Pack contents
Each pack contains, per control:
- Control metadata — id, name, category, description, framework-specific terminology (TSC, control objective, requirement).
- Status —
VERIFIED,WARNING,FAILED, orNOT_APPLICABLE. - Coverage classification —
fullif HarborGuard alone evidences the control,partialif it covers only the container layer. - Narrative — a "what we checked" / "why it matters" pairing for the auditor.
- Artifacts — CSV or JSON files generated from the live data (scan logs, vulnerability summaries, SBOMs, RBAC snapshots, etc).
Status grading
Status is computed from a list of passWhen rules per control. Each rule compares a metric (e.g. coverage, slaCompliance, breachCount, mttr) against a threshold using an operator (gte, lte, eq, in). When a rule fails, its onFail clause sets either a WARNING or FAILED status with a message explaining what missed the threshold.
| Status | Trigger |
|---|---|
VERIFIED | All passWhen rules satisfied. |
WARNING | At least one rule failed with onFail.status: WARNING. |
FAILED | At least one rule failed with onFail.status: FAILED. |
NOT_APPLICABLE | The control is not applicable to your environment (e.g. a sub-control marked NA in the policy). |
A control with coverage: "partial" is graded the same way, but the pack annotates it with partialReason so auditors understand which aspects are out-of-scope for HarborGuard and need separate evidence.
Automated vs manual evidence
| Aspect | Source |
|---|---|
| Scan coverage, MTTR, SLA compliance, severity counts | Computed automatically from scan and triage data. |
| Triage actions, attestations, policy edits | Captured automatically via the audit log. |
| RBAC and SSO configuration | Snapshotted automatically from organization settings. |
| Vendor management, business continuity, physical controls | Out of scope — auditors must combine HG output with separate evidence. |
partial controls (e.g. SOC 2 CC7.2 anomaly monitoring) | HarborGuard evidences the container layer; SIEM, IDS, and host monitoring evidence must come from elsewhere. |
The narrative.partialReason field on partial controls tells auditors exactly what is out of scope.
Generating a pack
- Navigate to Reports → Compliance Reports.
- Pick a framework from the active set (configured in Compliance → Policy → Active framework).
- Optionally narrow the scope to a registry, image, or tag set.
- Click Generate. The pack is produced as an immutable artifact bundle (control summary JSON + per-section CSV/JSON files).
Packs are retained per the org's reportRetentionDays setting (default 365).
Framework registry
The framework definitions — controls, mappings, pass rules, narratives, and required artifacts — are bundled with the platform. Currently registered: SOC 2, PCI DSS, NIST 800-190, NIST 800-53, NIST 800-171, ISO 27001, HIPAA, CMMC, CIS Docker, and FedRAMP. Each framework is updated alongside platform releases when the underlying standard changes.
For a custom or org-specific framework, set activeFramework to include CUSTOM and use the Report Builder to assemble the equivalent sections by hand.
See also
- Compliance Posture — pack outcomes flow into the dashboard
- Report Builder — exporting a pack as an evidence document
- Attestations — exception evidence attached to controls
- Audit Log — control evaluation audit trail