Integrations / Cloud & infrastructure
How do you continuously monitor Cloudflare for SOC 2, ISO 27001, and HIPAA?
Quick answer
Yes, you can run a SOC 2, ISO 27001, or HIPAA compliant service behind Cloudflare, but Cloudflare itself is not the thing that gets audited. Cloudflare certifies its own platform and publishes its own attestation reports for it. Your zone and account configuration, TLS mode, DNSSEC, WAF rules, account access, and API token hygiene are yours to get right and yours to evidence. Screenata runs 8 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Cloudflare with a read-scoped API token and runs 8 native checks against your account: SSL/TLS posture, DNSSEC, WAF configuration, account 2FA, and member roles. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog.
8 native checks · read-only · signed evidence
What it proves
Cloudflare evidence, mapped to controls.
TLS configuration on your zones, including whether traffic is served over encrypted connections at the settings your policies require.
Proof that data in transit to your applications is encrypted, on the scan date.
DNSSEC enablement on zones and WAF configuration at the edge.
Findings that the network boundary controls your system description names are actually enabled.
Two-factor authentication posture on the Cloudflare account.
Proof that access to a system controlling your DNS and edge requires strong authentication.
Account membership and role assignments, including how many members hold administrative roles.
Findings that account access follows least privilege and matches your access control policy.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Cloudflare, and why each matters.
Account Member 2FA
Verifies every accepted account member has two-factor authentication. A single-factor account controlling DNS and edge config is a high-value takeover target, and an auditor checks that access to it requires strong authentication.
Audit Log Access
Confirms the API token can read the account audit log. Without audit-log access there is no record of account changes to pull during an audit, and an auditor verifies administrative activity is logged and retrievable.
API Token Rotation
Checks that active API tokens were issued within the maximum age you set. Long-lived tokens widen the window for a leaked credential to be abused, and an auditor verifies access secrets are rotated on a schedule.
Zone WAF Enabled
Verifies each active zone has the web application firewall on. Without a WAF, application traffic reaches your origin unfiltered, and an auditor checks that the boundary protection your description names is enabled.
Zone DNSSEC Enabled
Confirms DNSSEC is active on each zone to protect against DNS spoofing. Without it, attackers can forge DNS responses and redirect users, and an auditor verifies DNS integrity controls are in place.
Zone SSL/TLS Strict + Always HTTPS
Verifies each zone uses strict SSL mode and forces HTTPS. Weaker modes leave origin traffic unvalidated or unencrypted, and an auditor checks that data in transit is encrypted end to end.
R2 Bucket Public Access
Checks that no R2 bucket is exposed over a public subdomain or custom domain. Public buckets bypass token-based auth and can leak data, and an auditor verifies storage access is restricted to authorized callers.
R2 Bucket Lifecycle Rules
Verifies each R2 bucket has a lifecycle rule for object deletion or cleanup. Without one, data lingers past its retention window, and an auditor checks that a data-retention story is enforced on object storage.
Drawn from Screenata’s Cloudflare check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
Cloudflare makes a Business Associate Agreement available on qualifying enterprise agreements, covering the services it designates as in scope, and it publishes SOC 2 reports for its own environment. Plan and service scope vary, so confirm with Cloudflare what your agreement covers before routing PHI through it. Whatever it covers, your zone and account configuration stays yours: TLS mode, DNSSEC, WAF rules, member roles, and two-factor authentication on the account are settings you own and evidence you have to produce.
What access does Screenata need to Cloudflare?
An API token scoped to read access that you create and control. Screenata uses it for scheduled scans and never receives write access to your zones or account settings. You can revoke the token at any time from your Cloudflare dashboard.
Why does Cloudflare matter for SOC 2?
DNS and the edge sit in front of everything else. An auditor reviewing boundary protection and transmission security wants evidence that TLS, DNSSEC, and the WAF are configured the way your system description claims, and that account access to those controls is itself protected.
What happens when a Cloudflare check fails?
Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your account is changed by Screenata; the connection is read-only by construction.
What are the steps to implement SOC 2 with Cloudflare?
First, connect the account with a read-scoped API token so the scan can see your zones and account settings without any write path. Second, let the first scan run and establish a baseline of where the account stands against the SOC 2 control set, instead of guessing which controls are already met. Third, fix what fails, which for most accounts means putting every zone on strict SSL with Always Use HTTPS, enabling DNSSEC and the WAF on active zones, requiring two-factor authentication on every account member, rotating API tokens that are older than your maximum age, and closing any R2 bucket exposed on a public domain. Fourth, let the scheduled scans collect the passing results as signed, timestamped evidence, so you build a history over the observation window rather than a single snapshot. Fifth, hand the evidence package to an independent auditor. The audit itself is a separate engagement you contract with a CPA firm; Screenata produces the evidence, it does not issue the report.
Is Cloudflare HIPAA compliant?
No provider is HIPAA compliant on its own, and Cloudflare does not claim to be. Cloudflare makes a BAA available on qualifying enterprise agreements for the services it designates as in scope, and compliance is a property of how you configure and operate what sits behind it. What makes the difference is TLS that is actually enforced end to end, DNSSEC and WAF protection on the zones carrying that traffic, controlled and two-factor-protected access to the account that governs those settings, audit log retention, and evidence that all of it held over time rather than on the one day you looked. Confirm the exact BAA scope with Cloudflare for your plan.
Do auditors accept evidence Screenata collects from Cloudflare?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Cloudflare, you know your real posture.
Related: AWS · GitHub · Google Cloud · Datadog