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¶

Seven framework and regulatory evidence sets 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 ships inside the product; the tables below document the same contract at control level.

CIS Microsoft Azure Foundations Benchmark v2.0.0¶

Section 8 - Key Vault.

CertifyClouds directly measures the 8.5 recoverability and 8.6 RBAC configuration checks. The other listed rows are supporting signals only. CIS 8.2 (non-RBAC vaults) and 8.4 (non-RBAC secrets) require customer 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.8 - Technological controls.

ISO 27001 contains 93 Annex A controls; CertifyClouds supplies supporting key and certificate lifecycle signals for the selected cryptography control above. 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¶

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 supplies supporting technical signals for four listed §164.312 provisions; it does not determine whether any HIPAA safeguard is implemented. §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¶

PCI-DSS v4.0.1 - 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 supplies supporting technical signals for four listed PCI-DSS v4.0.1 requirements; none is treated as a direct PCI control determination. 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 41 built-in rules across eight categories: secrets, certificates, keys, rotation pipeline, CIS Key Vault configuration, key management service (HSM), credential dependencies, and multi-cloud sync. 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 and custom-rule UIs, but deliberately do not appear in framework evidence packets.

The full catalogue - per-rule logic, evaluation thresholds, severities, and rule-to-control mappings - is available inside the product (Compliance -> Rules) and via the authenticated GET /api/compliance/rules endpoint. Every evidence packet lists the exact rules and versions it was generated from, so your auditor always sees the catalogue that applied to your scan.

Compliance score¶

Each product score is a weighted percentage of its evaluated passing rules. A rule only enters the denominator when it was actually evaluated; missing or failed evidence is reported as not evaluated or error, not credited as a pass. The headline score is the equal average of applicable, evaluated Discovery, Rotation, and Dependencies product scores. Sync is a separate operational-policy score and does not affect that headline. Each rule has a weight (1–30); custom rules contribute to their product.

The score is a technical evidence score, not a compliance rating. A complete score of 100 means all applicable, evaluated rules in the included products passed; 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¶

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, per-attachment SHA-256 hash manifest), and a 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 measures configured 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 added 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).