The security posture behind the security platform.

Yes, and it is enforced server-side, not just a checkbox on screen. Before a scan can be created, the user must confirm they are authorised to test the target. On creation we record an authorisation attestation against the assessment: the exact wording shown, the acting user, their IP and user agent, a timestamp, and a SHA-256 hash of the rendered text so any later tampering is detectable. A scan cannot start without that attestation on record. It is a hash-sealed evidence record rather than a digital signature.

CyberOrbit blocks all private and internal IP ranges at the infrastructure level: scans cannot be directed at your own internal network or cloud metadata endpoints. For external targets, the platform relies on the authorisation confirmation above. Any misuse violates our Terms of Service and we will terminate the account. We log the target URL, timestamp, and acting user ID for every assessment started.

All traffic between your browser, our API, and our scan workers uses TLS 1.3. Findings, evidence, and all customer data are encrypted at rest with AES-256. Database backups run on a Daily, Weekly, and Monthly schedule; each backup is encrypted with a separate key. Scan workers operate in isolated job processes: your findings never share memory with another customer's assessment.

Findings and reports are retained for the life of your subscription. On account closure, data is deleted within 30 days. You can export your full report (PDF + JSON) at any time from the dashboard. If you need earlier deletion, contact us via the legal form on our Privacy page.

Yes. Authenticated scanning is live: you can give a scan a session cookie, a bearer token, a custom header, or HTTP Basic credentials so our scanners reach login-gated endpoints, not just the public surface. You control how the credential is handled. By default it is used for a single run: encrypted with AES-256-GCM the moment you submit it, decrypted only inside the scanning worker for that one scan, never written to our database, and discarded when the run ends. It is single-use and auto-expires. If you opt into the encrypted Credential Vault to reuse a credential across scans, it is sealed with envelope encryption: we store ciphertext only, and the key that can decrypt it lives solely in the scanning worker, never in our web service or database. It is write-only so it can never be read back after you save it, expires within 90 days, and is crypto-erased the moment you delete it. In every mode the credential is stripped from logs, audit trails, and finding evidence by a load-bearing redaction control, so it never appears in a report or a reproduction command.

Findings are scoped to your organisation. No other customer, no third party, and no CyberOrbit staff member can query your findings via the product. Our internal staff access policy requires a support ticket and explicit customer consent before any engineer can inspect customer data. MSP accounts have a separate visibility boundary: MSP admins see their clients' attributions, not raw findings.

Every assessment runs in its own isolated execution context with no shared mutable state, and finding data is strictly org-scoped at the database layer with RBAC enforced on every API endpoint, so one customer's run can never read or affect another's. Our HTTP-based scanners share a worker process (isolated logically, not a container each). Our AI-driven active and exploit execution goes further: it runs in a per-run ephemeral Firecracker microVM (via E2B) that is destroyed after the run, with a hard, fail-closed network egress lockdown. Extending per-run container isolation to the general scanner path is on our infrastructure roadmap.

Yes. You can register the domains you are authorised to test as Authorised Targets and prove control of each with a DNS TXT record. Once a domain is verified, scheduled and continuous scans against it are hard-gated: our dispatcher checks the verified-target register before every run and refuses, fail-closed, if the target is not an active verified domain. Every scan is also blocked from private IP ranges, cloud metadata endpoints, and loopback addresses at creation. The register is domain (hostname) based today; we are extending the same hard enforcement to on-demand scans, and IP-range (CIDR) scopes are on the roadmap.

The full list is published in the Sub-processors section of this page and updated before any vendor change takes effect. Core customer data (findings, assessments) is hosted on managed PostgreSQL with one replica per region across US West, US East, EU West, and Southeast Asia. Scan worker infrastructure runs on Railway in the same four regions. Payment processing is handled by Stripe.

Yes. MSP admins have a dedicated dashboard showing all assessments attributed to each client. For any client you configure to require it, a pre-scan approval gate is enforced: an on-demand scan for that client is blocked and held as a pending request until an MSP admin approves it, and it cannot run until then. The gate is opt-in per client today, and we are extending it to scheduled runs.

Every assessment, finding, and report is tagged with an organisation ID. All API endpoints enforce org-scoped RBAC: a user in Organisation A cannot read, modify, or delete data belonging to Organisation B under any circumstances. MSP admins can see attribution metadata for their own clients only.

Yes. CyberOrbit is GDPR compliant. We process personal data only as necessary to deliver the service, maintain a sub-processor list (published on this page), provide a Data Processing Agreement on request, and support data subject rights including access, rectification, and erasure. Our Privacy Policy details what data we collect, why, and how long we retain it. If you need a DPA before starting a trial, contact us via the Privacy page form.

We are a pre-certification company. We do not currently hold SOC 2, ISO 27001, or equivalent certifications. We apply the same security practices we recommend to customers: encrypted data at rest and in transit, principle of least privilege, dependency scanning, and vulnerability remediation SLAs. SOC 2 Type I is on our near-term roadmap as we scale toward enterprise contracts.

Yes. We will execute a mutual NDA and a DPA before any trial or paid engagement that requires one. Contact us via the legal form on our Privacy page and we will turn them around within two business days.