Compliance Evidence¶

CertifyClouds produces audit-grade technical evidence for the narrow slice of cryptographic key + system-credential lifecycle controls in your Azure environment. CertifyClouds is not a compliance platform - your auditor determines compliance. CertifyClouds is one input to that determination.

What CertifyClouds evaluates¶

Five frameworks are mapped to CertifyClouds' rule engine. For each, the controls below cite the canonical control text and the CertifyClouds rule IDs that supply evidence. Coverage indicates how CertifyClouds' technical evidence aligns with the control:

• Direct technical evidence - the rule(s) directly demonstrate the control requirement in CertifyClouds' scope.
• Supporting technical evidence - the rule(s) contribute to but do not fully satisfy the control; your auditor will require additional evidence layered on top.
• Customer responsibility - CertifyClouds does not contribute evidence; the control depends on your Azure Monitor, Entra ID, SIEM, or organisational programme. The framework entry is included only to document the gap.

The authoritative mapping lives in backend/src/domains/compliance/constants.py (FRAMEWORK_CONTROLS). The list below is generated from that source.

CIS Microsoft Azure Foundations Benchmark v2.0.0¶

Section 8 - Key Vault.

CertifyClouds verifies 7 of 8 CIS Azure Key Vault controls. CIS 8.2 (non-RBAC vaults) and 8.4 (non-RBAC secrets) require manual verification outside CertifyClouds.

SOC 2 Type II (2017 Trust Services Criteria)¶

CC6 - Logical and Physical Access. CC7 - System Operations.

CertifyClouds provides technical evidence for 5 SOC 2 controls in the CC6 / CC7 families. Full SOC 2 compliance requires organisational policies, periodic access reviews, incident-response procedures, and audit attestation, all of which sit outside CertifyClouds.

ISO/IEC 27001:2022¶

Annex A.9 / A.10 - Cryptography.

ISO 27001 contains 93 Annex A controls; CertifyClouds verifies the cryptographic + secret-management subset. Full certification requires implementing all relevant Annex A controls and a third-party certification body audit.

NIST SP 800-53 Rev. 5¶

SC - System and Communications Protection. IA - Identification and Authentication. CM - Configuration Management.

NIST 800-53 has 20 control families and ~1000 controls. CertifyClouds contributes to 6 controls across SC / IA / CM. Full coverage requires comprehensive organisational implementation.

HIPAA Security Rule §164.312 (1.4.14)¶

45 CFR §164.312 - Technical Safeguards. Evidence mappings, not framework support. CertifyClouds is not a HIPAA-compliant data processor and is not a Business Associate. See the Compliance disclaimer for the full legal framing including the conditional BAA clause.

CertifyClouds provides technical evidence for 4 of 5 §164.312 subsections with partial coverage. §164.312(b) and §164.312(d) are Customer responsibility - see the customer-action audit logging and customer-action authentication enforcement sections below.

PCI-DSS v4.0 (1.4.14)¶

PCI-DSS v4.0 - Cryptographic Key Management (Req 3) + System Account Credentials (Req 8.6). Evidence mappings, not certification. CertifyClouds is not a PCI-DSS certified service provider; a Qualified Security Assessor (QSA) audit is required for an Attestation of Compliance.

CertifyClouds provides direct or partial technical evidence for 7 PCI-DSS v4.0 requirements. Requirement 10 (audit logging of CHD-system access) is Customer responsibility - see customer-action audit logging. Requirements 1, 2, 4, 5, 6, 7, 9, 11, and 12 are out of scope.

Azure Security Benchmark v3.0¶

Microsoft's own benchmark - correlates with Defender for Cloud recommendations. Visible in Azure Portal → Defender for Cloud → Regulatory Compliance.

LT-3 is explicitly marked Customer responsibility because CertifyClouds does not collect Azure Diagnostic Settings logs. Enable diagnostic logging on every Key Vault in scope and forward to Log Analytics; see Customer action - audit logging below.

Compliance rules¶

CertifyClouds ships 40 built-in rules. The rule engine runs them against every scan, weights pass/fail by severity, and computes a 0–100 score. Rules fall into two classes:

• Framework-mapped rules - referenced by at least one framework control (above). Contribute to per-framework evidence packets.
• Operational hygiene rules - not bound to any compliance framework. Surface in operational dashboards, custom-rule UIs, and the overall score, but deliberately do not appear in framework evidence packets (no compliance framework actually requires them).

Secret rules¶

Certificate rules¶

Key rules¶

Rotation rules¶

CIS Key Vault rules¶

Key Management Service (KMS) rules¶

Dependency rules¶

Multi-cloud sync rules¶

Compliance score¶

The compliance score is the weighted percentage of passing rules:

score = (Σ weight × passed) / (Σ weight × all_applicable) × 100

Each rule has a weight (1–30) reflecting its impact. Severity is indicative; the weight governs the math. Custom rules contribute too.

The score is a technical evidence score, not a compliance rating. A score of 100 means CertifyClouds' rules all pass; it does not mean you are HIPAA-, PCI-, or any-framework compliant.

Custom rules¶

PRO tier supports creating custom compliance rules with a structured condition predicate (no scripting, no DSL). The evaluator is sandboxed by a whitelist of operators, asset fields, and scopes - there is no code-execution surface.

Condition shape¶

A custom rule's condition is a JSON object with four fields:

Examples¶

Flag secrets without a production tag:

{
  "operator": "not_exists",
  "asset_field": "tag_present",
  "asset_scope": "secrets",
  "value": "env=production"
}

Warn on certificates older than 365 days:

{
  "operator": "less_than",
  "asset_field": "expires_within_days",
  "asset_scope": "certificates",
  "value": 30
}

API¶

• GET /api/compliance/rules - list all rules (built-in + custom)
• POST /api/compliance/rules - create custom rule (admin, 10/min)
• PUT /api/compliance/rules/{rule_id} - update custom rule (admin, 20/min)
• DELETE /api/compliance/rules/{rule_id} - delete custom rule (admin, 10/min)

Built-in rule IDs (P*, C*, K*, VM*, SYN*, CIS-*) are read-only and cannot be modified via the API.

Evidence reports (1.4.14)¶

CertifyClouds produces auditor-grade evidence packets in CSV + PDF bundle form. Each report contains the data CSV, a PDF wrapper with cover page (tenant, scope, CertifyClouds version, RFC 3161 cryptographic timestamp, SHA-256 hash manifest), and a signed customer management assertion block.

Report types available:

1. CC operator audit log (hash-chained, HMAC-manifest signed)
2. Full rotation event population over an audit period
3. Per-vault RBAC + network posture snapshot
4. Dependency / blast-radius bulk export
5. Multi-cloud sync provenance (source + target hashes)
6. Recoverability posture per vault
7. Compliance rule violation report with affected-asset samples
8. Cryptoperiod conformance (asset age vs declared cadence)
9. Algorithm strength conformance (FIPS 140-3 / PCI minimums)
10. KV asset inventory (algorithm, key size, expiry, last rotated)

Each report exposes a format=csv or format=pdf query parameter and accepts from/to ISO 8601 timestamps for audit-period filtering. All reports are admin-gated.

See Generating evidence reports for the per-report schema and customer management assertion template.

What CertifyClouds does NOT evaluate¶

These belong to your overall compliance programme. CertifyClouds does not contribute evidence and does not claim to.

Customer action - audit logging¶

CertifyClouds does not collect Azure Key Vault access logs. HIPAA §164.312(b), PCI-DSS Requirement 10, SOC 2 CC7.2, and Azure Security Benchmark LT-3 all require access logging on data stores.

To close the gap:

1. Enable Azure Diagnostic Settings on every Key Vault in scope.
2. Forward to a Log Analytics Workspace with retention per your framework (HIPAA: 1 year minimum; PCI: 1 year online + 3 months hot per Req 10.5.1).
3. Configure Azure Defender for Key Vault for anomalous-access alerts.
4. Connect Log Analytics to your SIEM for cross-system correlation.

Customer action - authentication enforcement¶

CertifyClouds does not enforce MFA and does not see Entra ID sign-in events. HIPAA §164.312(d), PCI 8.3, SOC 2 CC6.1, and ASB IM-* require this.

To close the gap:

1. Configure Entra ID Conditional Access requiring MFA on all users with Key Vault Reader / Secret User / Crypto User roles.
2. Use Privileged Identity Management for time-bound elevated roles.
3. Document break-glass procedures.

Customer action - encryption at rest beyond Key Vault¶

CertifyClouds verifies Key Vault key strength and recoverability. It does not verify encryption configurations on Storage Accounts, Azure SQL, managed disks, Cosmos DB, or other Azure services.

To close the gap:

1. Audit each in-scope service's encryption-at-rest configuration.
2. Adopt customer-managed keys (CMK) backed by Premium-SKU Key Vaults for highest-trust workloads. (CertifyClouds 1.4.14 adds a CMK-detection rule for Key Vaults; see release notes.)

Customer action - organisational policies¶

CertifyClouds is a technical evidence aggregator, not a policy authoring or training tool. Your compliance programme also requires:

• A documented information security policy
• Security Officer / Privacy Officer assignment (HIPAA §164.308(a)(2))
• Annual risk assessment
• Workforce training records
• Incident response procedures
• Business Associate Agreements with downstream processors (HIPAA)
• Key custodian acknowledgement forms with split-knowledge attestation (PCI 3.6.1.1)

These artefacts are produced by your compliance team or a qualified service provider, not by CertifyClouds.

Audit workflow with CertifyClouds¶

The recommended workflow for using CertifyClouds output during an audit:

1. Scope statement - produce a written list of in-scope Azure subscriptions / Key Vaults / App Registrations. Reconcile against az resource list to prove completeness.
2. Evidence generation - generate the per-control evidence reports for the audit period via the CertifyClouds Compliance tab → Generate Evidence Bundle.
3. Management assertion - sign the assertion block in each PDF bundle, stating that the scan covered the listed scope, was run by the named actor, and the output reflects system state at the timestamp shown.
4. Hand off to auditor - provide the signed bundles + your scope statement. The auditor will validate the SHA-256 / HMAC manifest against the included CSV.
5. Audit determination - the auditor combines CertifyClouds' evidence with your other controls (audit logs, MFA configuration, organisational policies, etc.) and makes the compliance determination.

CertifyClouds is one input to step 5. The determination itself is outside CertifyClouds' scope.

Disclaimer¶

See the full legal framing on the Compliance disclaimer page, including:

• Customer responsibility for placing Protected Health Information, Cardholder Data, or other regulated content into Azure resource names or tags;
• The conditional Business Associate Agreement clause;
• The explicit reliance disclaimer (no customer may rely on CertifyClouds reports as a determination of compliance).