Which connection model fits your own compliance posture?

Direct connection

• ☑A single AssumeRole/External-ID trust relationship, never a static access key — scoped to exactly the read-only actions the rule engine needs

• ☐Raw resource configuration (IAM policies, security group rules, VPC layouts) transits to and is stored in Cloud Compliance's own database — this makes Cloud Compliance a genuine sub-processor in your own SOC 2 vendor-risk assessment, not a tool you can wave through

In-account collector

• ☑No cross-account trust policy exists at all — the collector runs on infrastructure you own, using a locally-owned IAM role/ServiceAccount that never mentions Cloud Compliance's own AWS account
• ☑Only findings (rule_id, severity, category, the narrow evidence dict) cross the network — never the full raw configuration

• ☐The findings that do leave still reach Cloud Compliance's database, so a (much narrower) sub-processor relationship still exists — document it, don't assume it away

Fully self-hosted

• ☑Nothing leaves your network at all — backend, worker, and database all run on your own infrastructure. No sub-processor relationship exists to assess

Direct connection

• ☑The AssumeRole permission set is narrowly scoped and published (not the AWS-managed ReadOnlyAccess policy) — auditable against exactly what it can reach

• ☐Concentration risk is real, not just theoretical: a compromise of Cloud Compliance's own AWS account would expose every direct-connection customer's role at once — your own risk register should reflect that, this tier doesn't remove the question

In-account collector

• ☑No cross-account trust means the concentration-risk question above doesn't apply — compromising Cloud Compliance's own infrastructure grants no path into your account

• ☐The collector's own container image and its scoped API key are still things your own supplier-relationship review should cover, even though the trust boundary is narrower

Fully self-hosted

• ☑No infrastructure relationship to review at all — Cloud Compliance has no access to consider under this tier

Direct connection

• ☑Raw cloud configuration is rarely personal data itself (IAM policies, security groups, VPC layouts) — but where a finding's evidence happens to surface something that is (a resource tag, a database identifier), Cloud Compliance is processing it as your processor, under a data processing agreement, same as any other sub-processor

• ☐Where that data is stored (Cloud Compliance's own database, its own region) is a residency question this tier doesn't avoid — check it against your own obligations rather than assuming it away

In-account collector

• ☑Only findings cross the network, narrowing what could ever be personal data to the evidence dict alone — and `--include-raw-config` is opt-in, off by default

Fully self-hosted

• ☑Nothing leaves your own infrastructure or jurisdiction — the residency question doesn't arise

Direct connection

• ☑A financial-services customer can point at the exact permission set and the fact that this is read-only, never a write/execute capability — Cloud Compliance never remediates, only reports

• ☐DORA's third-party register and concentration-risk assessment still apply in full — this tier is a standing external dependency, the same concentration-risk point as ISO 27001 above, specifically relevant to DORA's own emphasis on it

In-account collector

• ☑No cross-account trust and only findings leaving materially reduces what a DORA third-party assessment needs to cover, compared to the direct-connection tier

• ☐Still an external dependency for the findings-ingestion endpoint itself — a narrower entry in the third-party register, not a zero entry

Fully self-hosted

• ☑No external ICT third-party dependency for this function at all — the tier several DORA-regulated customers choose specifically for this reason

Direct connection

• ☑Cloud Compliance's own read-only role requirement models exactly the least-privilege access control principle Cyber Essentials asks you to apply to your own systems

In-account collector

• ☑The collector you run yourself is inside your own boundary firewall scope — its patching/access control is already part of your existing Cyber Essentials boundary, not a new external dependency

Fully self-hosted

• ☑The entire platform sits inside your own Cyber Essentials boundary — its own hardening is yours to assess, using the same standard you'd apply to any other self-run service

Direct connection

• ☑Principle 8 asks you to understand how a supplier protects the data you hand it — the read-only, narrowly-scoped AssumeRole model is exactly what to point at

• ☐Raw configuration data still leaves your own supply chain boundary and enters Cloud Compliance's — Principle 8's own due-diligence expectations apply in full

In-account collector

• ☑No cross-account trust narrows the supply-chain question to the findings-ingestion endpoint alone, not full account access

Fully self-hosted

• ☑No supply chain question for this function — it runs entirely inside infrastructure already in your own assessed boundary

Direct connection

• ☑Read-only, always — Cloud Compliance has no write or execute capability against any customer resource in any tier, unlike a remediation tool. If the scanned account is CDE-adjacent, the access is Describe/List/Get-only

• ☐Scope isn't automatically "out" — if the AssumeRole reaches CDE-adjacent resources, that access itself belongs in your own PCI-DSS assessment as a service-provider relationship, not assumed away because it's read-only

In-account collector

• ☑No cross-account trust into the CDE-adjacent account at all — the collector runs with a locally-owned role you control directly

• ☐Still worth naming in your own segmentation/scope documentation if the collector's own read access reaches CDE-adjacent resources

Fully self-hosted

• ☑No third-party service-provider question arises at all — Cloud Compliance has no access to your infrastructure to consider