Compliance Disclaimer¶

Effective date: 2026-05-20 Last reviewed: 2026-05-20

This page is the authoritative legal framing for any compliance-related claim CertifyClouds makes - in product, in documentation, on the marketing website, in pricing or terms documents, or in any sales material. Public references to HIPAA, PCI-DSS, SOC 2, ISO 27001, NIST 800-53, CIS Azure, Azure Security Benchmark, or any other framework are subject to the terms below.

Summary¶

• CertifyClouds is not a compliance platform. It is an evidence aggregator for cryptographic key + system-credential lifecycle controls.
• CertifyClouds does not certify, attest, or determine compliance. Your auditor makes the compliance determination using CertifyClouds' evidence as one input among many.
• CertifyClouds is not a Business Associate under HIPAA and is not a PCI-DSS certified service provider. It is offered on the basis that customers do not provide Protected Health Information (PHI) or Cardholder Data (CHD) to CertifyClouds.
• CertifyClouds reports may not be relied upon as a determination of HIPAA, PCI-DSS, SOC 2, ISO 27001, NIST 800-53, or Azure Security Benchmark compliance.

What CertifyClouds collects and processes¶

CertifyClouds operates against the Azure SDK and ingests, displays, exports, and transmits the following customer-controlled metadata:

• Azure Key Vault names and configuration (RBAC mode, network access flags, soft-delete + purge-protection state)
• Names, tags, expiry timestamps, and lifecycle properties of secrets, certificates, and keys stored in Key Vaults
• Azure App Registration display names, client IDs, object IDs, and credential expiry information
• Azure subscription identifiers and resource identifiers for dependency mapping
• Multi-cloud sync configurations and execution history

CertifyClouds does not intentionally collect:

• Secret values, certificate private keys, or cryptographic key material
• Cardholder Data (CHD), Personal Account Numbers (PANs), or magnetic stripe data
• Protected Health Information (PHI), electronic Protected Health Information (ePHI), or clinical record content
• Customer business data, transaction data, or production data
• Azure Diagnostic Settings logs, Azure Monitor data, or Entra ID sign-in events

Customer responsibility for sensitive metadata¶

The metadata CertifyClouds collects is customer-controlled. Customers must not place PHI, CHD, or any other regulated sensitive content into Azure resource names or tags scanned by CertifyClouds.

Examples of customer-controlled fields where regulated content must not appear:

• Key Vault names (e.g. do not name a vault hospital-records-prod if "records" implies records of identifiable patients)
• Secret, certificate, and key names (e.g. do not name a secret patient-john-doe-ssn-2026)
• Azure resource tags (e.g. do not tag with {"patient_id": "..."})
• App Registration display names that identify specific customers, patients, accounts, or transactions

If a customer requires CertifyClouds to scan environments where such content cannot be excluded from Azure resource metadata, the customer must enable CertifyClouds' PHI-safe metadata mode (introduced in 1.4.14), which applies HMAC redaction to vault, asset, and tag values at ingest. Operation without PHI-safe metadata mode in environments containing regulated metadata is not supported.

Business Associate Agreement (BAA) and HIPAA¶

CertifyClouds is offered on the basis that customers do not provide Protected Health Information to CertifyClouds. CertifyClouds is not a Business Associate under HIPAA in the default configuration.

If a customer requires CertifyClouds to receive PHI through any channel - including in resource names, tags, or any other field - such use is not supported absent a separately executed Business Associate Agreement. Customers requiring a BAA should contact CertifyClouds sales to discuss whether a tailored arrangement is available; CertifyClouds reserves the right to decline.

CertifyClouds' technical evidence covers selected HIPAA Security Rule §164.312 Technical Safeguards. Specifically:

• §164.312(a)(1) Access Control - Supporting technical evidence
• §164.312(a)(2)(iv) Encryption and Decryption - Supporting technical evidence (becomes Direct in 1.4.14 with the CMK-detection rule)
• §164.312(b) Audit Controls - Customer responsibility (CertifyClouds does not collect Azure access logs)
• §164.312(c)(1) Integrity - Supporting technical evidence
• §164.312(d) Person or Entity Authentication - Customer responsibility (CertifyClouds does not enforce or audit MFA)
• §164.312(e)(1) Transmission Security - Supporting technical evidence

§164.308 Administrative Safeguards (Security Officer assignment, training, risk assessment, contingency plan) and §164.310 Physical Safeguards are outside CertifyClouds' scope.

PCI-DSS¶

CertifyClouds is not a PCI-DSS certified service provider and does not process, store, or transmit Cardholder Data. CertifyClouds is not in the Cardholder Data Environment (CDE) attestation scope.

CertifyClouds' technical evidence covers selected PCI-DSS v4.0 requirements, primarily under Requirement 3 (Protect Stored Account Data - cryptographic key management) and Requirement 8.6 (Accounts Used by Systems and Applications). Coverage indicators ("Direct technical evidence" or "Supporting technical evidence") describe the technical contribution to the named requirement and do not constitute a PCI-DSS Attestation of Compliance (AoC).

A Qualified Security Assessor (QSA) audit of the customer's CDE is required for an AoC. CertifyClouds' output is one input the customer may provide to the QSA.

SOC 2, ISO 27001, NIST 800-53, Azure Security Benchmark¶

For each of these frameworks, CertifyClouds' technical evidence covers a subset of controls relevant to cryptographic key and system- credential lifecycle. See the Compliance Evidence page for the per-control mapping with coverage indicators.

CertifyClouds is not SOC 2 Type II–attested, not ISO 27001- certified, not FedRAMP-authorised, and not assessed under any NIST 800-53 baseline as a service provider. References to these frameworks describe the technical control families to which CertifyClouds' rule engine produces evidence; they are not service- provider attestations.

Reliance disclaimer¶

The customer may not rely on CertifyClouds reports, rule violations, compliance scores, evidence packets, or other CertifyClouds output as a determination of compliance with any regulatory framework, contractual requirement, or industry standard. CertifyClouds output is one input the customer may provide to their auditor, Privacy Officer, Qualified Security Assessor, lead auditor, or compliance counsel. The compliance determination itself is made by those parties based on their professional review of the totality of the customer's controls, policies, and evidence.

To the maximum extent permitted by applicable law, CertifyClouds disclaims all liability arising from a customer's reliance on CertifyClouds output as a substitute for the determination described above.

Coverage indicators¶

CertifyClouds tags every control mapping with a coverage indicator:

• Direct technical evidence - CertifyClouds' rules directly demonstrate the technical control requirement in CertifyClouds' scope. The customer's auditor typically requires additional organisational, procedural, and personnel controls layered on top.
• Supporting technical evidence - CertifyClouds' rules contribute to but do not fully satisfy the technical control. The customer's auditor will require additional technical evidence (from other tools, services, or manual review) on top.
• Customer responsibility - CertifyClouds does not contribute technical evidence to the control. The control is listed in the mapping only to document the gap and direct the customer to the appropriate Azure, Microsoft, or third-party control. Examples include HIPAA §164.312(b) Audit Controls (depends on Azure Diagnostic Settings) and HIPAA §164.312(d) Person or Entity Authentication (depends on Entra ID Conditional Access).

Coverage indicators describe technical contribution. They do not describe legal compliance.

Marketing copy guardrails¶

The following statements about CertifyClouds are never permitted in marketing, sales, product, or documentation copy:

• "CertifyClouds is HIPAA compliant"
• "CertifyClouds is PCI-DSS compliant"
• "CertifyClouds is SOC 2 / ISO 27001 / NIST 800-53 certified"
• "CertifyClouds makes your environment HIPAA / PCI / SOC 2 / ISO / NIST compliant"
• "CertifyClouds eliminates the need for an audit"
• "CertifyClouds replaces a Qualified Security Assessor"
• "CertifyClouds satisfies HIPAA §164.312(b)" (or any other Customer-Responsibility control)
• "No BAA required" (without the conditional clause from Business Associate Agreement (BAA) and HIPAA above)

Permitted phrasings:

• "CertifyClouds produces evidence for the technical controls your auditor evaluates"
• "CertifyClouds verifies cryptographic key + system-credential lifecycle controls in your Azure environment"
• "CertifyClouds is one input to your compliance programme"
• "CertifyClouds' evidence contributes to your auditor's determination"
• "CertifyClouds' rule mappings cover [X] of the [framework's] technical key-management controls" (with the per-framework mapping page linked)

When in doubt, link to this page.

Version history¶

Questions¶

Compliance posture questions for CertifyClouds: support@certifyclouds.com.

Compliance posture questions for your environment: your auditor, Privacy Officer, or compliance counsel. CertifyClouds cannot determine your compliance status.