1. Security philosophy
Cloudryption is built for security teams that need decision-quality context, not more disconnected alerts. The platform is designed to model customer-authorised cloud reality, explain why risk matters, and show which minimal fixes reduce the most material exposure.
Because the platform processes sensitive cloud configuration and security metadata, Cloudryption treats customer metadata as security-sensitive even when it is not traditional personal data. We apply the same rigour to protecting your security posture data that we help you apply to your cloud environments.
2. Architecture summary
The platform includes a web UI, API service, ingestion and scan workers, cloud connectors, a normalisation layer, a graph snapshot store, findings and control engines, an attack-path engine, recommendation and remediation logic, reporting, audit logging, and optional AI-assisted narrative generation.
Core computation is run-scoped: findings, attack paths, recommendations, and reports are linked to the same tenant, environment, scan run, and graph snapshot to prevent stale or cross-run decisions.
Customer environments are connected only when authorised by the customer. Connector permissions are scoped to read-only or minimum required privileges except where a customer explicitly enables remediation workflows.
3. Encryption in transit and at rest
In transit:
- HTTPS/TLS for all customer browser and API connections
- TLS for internal service-to-service and database connections
- Obsolete TLS protocols (TLS 1.0, 1.1) and weak cipher suites are disabled at the production edge
At rest:
- Cloud provider and database-native encryption at rest for production databases, object storage, and backups
- Key management via cloud KMS with access restricted to required service roles and administrators
- Plaintext secrets are not stored in source code, logs, tickets, exports, or customer-visible reports
Full details are in the Encryption & Security Architecture Summary.
4. Tenant and run isolation
All application logic enforces tenant_id and user role before reading or modifying any tenant data. Scan outputs are scoped by tenant_id, env_id, and run_id. Findings, attack paths, recommendations, reports, and evidence reference the graph snapshot used for calculation.
The data model and query patterns are covered by cross-tenant negative tests to detect isolation regressions. These tests run in CI on every pull request.
5. Cloud connector security
Cloudryption recommends and supports cloud-native role assumption, workload identity, and delegated read-only roles. Where credentials must be stored, they are stored encrypted in a secrets manager or encrypted credential store with access restricted by service role.
Connector setup, changes, and scan failures are logged. Secret values are never logged. Credential rotation and revocation procedures are documented and tested.
6. Access control
Cloudryption operates least-privilege access for internal systems and production environments. The platform provides tenant-aware RBAC for customer users:
- Tenant Admin: manages tenant users, environments, connectors, and settings
- Security Admin: manages scans, findings, remediation planning, and exports
- Security Analyst: views findings, attack paths, evidence, and reports
- Viewer / Executive: read-only dashboards and reports
- Auditor: read-only access to audit logs, reports, and evidence
- API / Service Account: scoped API access for automation
Administrative access to production is restricted, logged, reviewed, and revoked promptly when no longer required. Full details are in the Access Control Policy Summary.
7. Secure software development
Cloudryption's secure SDLC includes:
- Mandatory code review for all changes to production code
- Automated CI pipeline with build, test, and vet checks on every pull request
- Dependency scanning and software bill of materials (SBOM) generation
- Container and filesystem vulnerability scanning (Trivy) before production deployments
- Secret scanning to detect accidental credential commits
- Pinned Go toolchain version aligned with CI (see project CI configuration)
- Production deployments require passing CI and authorised approval
8. Audit logging
Cloudryption logs the following categories of events:
- Authentication events: login, logout, failed attempts, MFA, SSO
- Administrative actions: user management, role changes, connector setup and deletion
- Scan lifecycle: scan start, completion, failure, and recalculation events
- Report and data exports: export requests, export recipients
- Privileged access: production access events, break-glass access
Audit logs are retained for a minimum of 365 days for enterprise tenants. Logs are write-protected and access is restricted to authorised personnel.
9. Vulnerability management
Security patches and critical dependency updates are triaged based on severity (CVSS), exploitability, exposure, and customer impact. Cloudryption maintains a vulnerability register and tracks remediation timelines.
Researchers may report vulnerabilities under the Responsible Disclosure Policy.
10. Incident response
Cloudryption maintains a documented incident response process covering preparation, detection, containment, eradication, recovery, customer notification, and post-incident review.
For confirmed incidents affecting Customer Data, Cloudryption targets customer notification within 48 hours of confirmation. Full details are in the Incident Response Policy Summary.
11. SOC 2 status
Not yet certified. SOC 2 readiness is built into architecture; audit engagement is roadmapped.
12. Remediation safety
Write operations disabled by default. When enabled, subject to approval workflows and customer-defined authorization controls.
13. Shared responsibility
Customers remain responsible for their own cloud accounts, identity providers, user access, connector permissions, remediation approval, and compliance obligations. Cloudryption provides prioritisation and evidence but does not guarantee prevention of every security incident or detection of every vulnerability.
14. Control overview
| Area | Public statement |
|---|---|
| Tenant isolation | Protected through application-layer scoping, database isolation, authorization controls, and negative testing. Customer data is logically separated by tenant and environment. |
| Cloud connectors | Customers authorise connectors with least-privilege permissions. Credentials are encrypted at rest. Connector events are logged. |
| Encryption | TLS in transit; cloud-native KMS-backed encryption at rest for databases, backups, and object storage. |
| Access control | Tenant-aware RBAC. MFA for privileged users. Production access is least-privilege, logged, and reviewed. |
| Audit logging | Authentication, admin, scan, export, and connector events are logged and retained for ≥ 365 days for enterprise tenants. |
| Secure SDLC | Code review, CI checks, dependency and container scanning, SBOM generation on every release. |
| Vulnerability management | Severity-based patch triage with tracked remediation timelines. Responsible disclosure policy published. |
| Incident response | Documented IR process with 48-hour customer notification target for confirmed data breaches. |
| Backup & DR | Encrypted backups, tested restore procedures, defined RPO / RTO targets. See Backup & DR Summary. |
| SOC 2 | Not yet certified. Security programme is building toward SOC 2 readiness. See SOC 2 Roadmap. |
15. Security contact
Report security vulnerabilities or concerns to: security@cloudryption.com
For the vulnerability reporting process, see the Responsible Disclosure Policy.
For enterprise security due diligence, see the Security Questionnaire or contact your account representative.