OrbitalReg

Appearance

ISO/IEC 27001:2022 Annex A controls mapping ​

This page maps the 93 controls of ISO/IEC 27001:2022 Annex A to the OrbitalReg features that satisfy or substantiate them. Use it during procurement reviews, internal audits, and Statement-of-Applicability (SoA) drafting — the goal is to compress what would otherwise be a six-week back-and-forth with security teams into a 20-minute reading session.

How to read this page

For each control we publish:

  • Status — one of:
    • Implemented — the OrbitalReg-shipped behaviour satisfies the control with default-secure settings.
    • Configurable — OrbitalReg ships the mechanism but the operator must enable or tune it for their environment (SSO, retention, pull-gate, …).
    • Customer-side — the control sits in the customer's wider governance, HR, or facilities programme. OrbitalReg may produce evidence that supports it but does not satisfy it alone.
  • Feature — the OrbitalReg surface that backs the control.
  • Evidence — what an auditor should ask for, and where it lives (file path, admin URL, API endpoint, runbook).

Scope

This mapping is informational. ISO/IEC 27001 certification is granted by an accredited certification body against your organisation's Information Security Management System (ISMS) — not against OrbitalReg. The controls below describe how OrbitalReg helps you meet the technical and operational expectations Annex A places on a self-hosted artifact registry, not a substitute for the management- system work (Clauses 4–10) you need to do separately.

A.5 — Organizational controls (37) ​

A.5.1 Policies for information security ​

  • Status: Customer-side
  • Feature: OrbitalReg's per-deployment branding card surfaces operator-authored policy URLs (Help button, login banner) but the policy text itself is your responsibility.
  • Evidence: Air-gapped operations guide + Admin > Branding > Help URL.

A.5.2 Information security roles and responsibilities ​

  • Status: Configurable
  • Feature: Project-scoped RBAC (viewer / editor / owner) plus global admin; service-account ownership tied to projects.
  • Evidence: Admin > Users; /api/v1/projects/{id}/role-bindings; Architecture > Identity model.

A.5.3 Segregation of duties ​

  • Status: Configurable
  • Feature: Promotion gate splits create-pending from execute; CVE/license policies block self-approval. Pull-gate policies and security-block creation gated by admin role.
  • Evidence: /api/v1/promotions/{id}/execute; Concepts > Promotion gate.

A.5.4 Management responsibilities ​

  • Status: Customer-side
  • Feature: OrbitalReg surfaces operational health (license, backup-verification, alert dashboards) so management has read-only evidence of control performance.
  • Evidence: Admin > Overview; /admin/license; Backup verification.

A.5.5 Contact with authorities ​

  • Status: Customer-side

A.5.6 Contact with special interest groups ​

  • Status: Customer-side
  • Feature: OrbitalReg consumes upstream CVE feeds (OSV, NVD via Trivy/Grype) and Sigstore Rekor so the operator's vulnerability programme stays current with the wider community.
  • Evidence: Concepts > Scanning; Admin > Sigstore policies.

A.5.7 Threat intelligence ​

  • Status: Implemented
  • Feature: Detection workers (Trivy / Grype / Syft / OSV) re-scan every artifact on upstream feed updates; auto-quarantine flips the quarantined bit when a new CVE matches an in-registry artifact; pull-gate policies can shadow-evaluate proposed enforcement before going live.
  • Evidence: /api/v1/detection/findings; scan_findings table; Concepts > Scanning; Admin > Pull-gate.

A.5.8 Information security in project management ​

  • Status: Customer-side

A.5.9 Inventory of information and other associated assets ​

  • Status: Implemented
  • Feature: Every artifact carries (repo_id, path, version, sha256, size, JSONB metadata); build-info aggregates per-build CycloneDX 1.5 SBOMs; cross-repo /api/v1/search covers 42 package formats.
  • Evidence: /api/v1/projects/{id}/build-info/{name}/{number}/sbom; Concepts > Build-info; Reference > REST API.

A.5.10 Acceptable use of information and other associated assets ​

  • Status: Customer-side
  • Feature: OrbitalReg publishes per-pull audit (artifact_pulls) so the operator's acceptable-use policy is enforceable post-hoc.
  • Evidence: /api/v1/artifacts/{id}/pulls; Operations > Structured logs.

A.5.11 Return of assets ​

  • Status: Configurable
  • Feature: Service-account token revoke (/api/v1/projects/{p}/ service_accounts/{id}/tokens/{tid}/revoke); session invalidation on user deactivation; project archive disables the asset class without deleting history.
  • Evidence: Admin > Users > Deactivate; /api/admin/audit?event= user.deactivate.

A.5.12 Classification of information ​

  • Status: Configurable
  • Feature: Per-repo visibility (public / internal / private), per-project license-policy classification (allowed / disallowed / review), and pull-gate scope-of-effect (global / project / repo / artifact) provide a four-tier classification model.
  • Evidence: Repo settings > Visibility; Concepts > License compliance.

A.5.13 Labelling of information ​

  • Status: Implemented
  • Feature: Artifacts carry format-typed metadata; security blocks surface a customer_message rendered on the public block page; build-info attaches SBOM identifiers (orbitalreg:role properties on every CycloneDX component).
  • Evidence: /api/v1/artifacts/{id}; /blocked/{block_id} public page.

A.5.14 Information transfer ​

  • Status: Implemented
  • Feature: All inbound/outbound transfer is HTTPS (NGINX + cert-manager); webhook URLs validated as https:// at CRUD; HMAC-signed webhook bodies; geo-sync apply uses signed bearer tokens; OIDC token-exchange replaces long-lived PATs in CI.
  • Evidence: Installation guide; OrbitalRegWebhookSubscription CRD; Concepts > OIDC token exchange.

A.5.15 Access control ​

  • Status: Implemented
  • Feature: RBAC enforced at every handler; bundled scopes (Pull / Publish / Admin) on tokens with optional format and repo filters; sessions in Redis with idle and absolute expiry.
  • Evidence: Architecture > Identity; Admin > API tokens; /api/v1/whoami.

A.5.16 Identity management ​

  • Status: Configurable
  • Feature: SAML 2.0 + OIDC SSO (Azure Entra, Okta, Keycloak); local account creation disabled when SSO is configured; service-account identity tied to project.
  • Evidence: Admin > Authentication; /api/admin/saml/config; Architecture > SSO.

A.5.17 Authentication information ​

  • Status: Implemented
  • Feature: Service-account token plaintext returned exactly once on creation; HMAC webhook secrets are write-only via the API (has_secret: bool on read); operator-supplied SAML signing keys encrypted at rest in the database.
  • Evidence: /api/v1/projects/{p}/service_accounts/{id}/tokens (POST 201 body schema); operator log: component=auth event=sa_token.minted.

A.5.18 Access rights ​

  • Status: Implemented
  • Feature: Role-binding lifecycle (grant / revoke / expire) audited to audit_events; quarterly access-review query published in Operations > Structured logs > Sample queries.
  • Evidence: audit_events table filtered by event LIKE 'role_binding.%'.

A.5.19 Information security in supplier relationships ​

  • Status: Configurable
  • Feature: Importers (internal/imports/...) bring upstream registry inventories under unified governance: JFrog, Sonatype Nexus, GitHub Packages, GitLab Package Registry, Azure Artifacts, AWS CodeArtifact, Google Artifact Registry. CNPG image catalog mirror brings third-party container images under registry control.
  • Evidence: Admin > Imports; Concepts > Importers.

A.5.20 Addressing information security within supplier agreements ​

  • Status: Customer-side

A.5.21 Managing information security in the ICT supply chain ​

  • Status: Implemented
  • Feature: Trust bundles (CMS / OpenPGP / RSA) verify on pull; Sigstore/cosign keyless verification with admin-managed sigstore_trust_policies; build-info captures producer + dependency SBOM at upload.
  • Evidence: Admin > Trust; Admin > Sigstore policies; Concepts > Build-info.

A.5.22 Monitoring, review and change management of supplier services ​

  • Status: Configurable
  • Feature: Importer jobs surface success / failure / dedup counts; CNPG image catalog mirror sync status published per run.
  • Evidence: Admin > Imports > Job history; Admin > CNPG catalog.

A.5.23 Information security for use of cloud services ​

  • Status: Customer-side
  • Feature: OrbitalReg is self-hosted; the operator chooses where to run it. CloudNativePG + S3 abstractions let the same binary run on AWS, GCP, Azure, or on-premise.
  • Evidence: Installation guide.

A.5.24 Information security incident management planning and preparation ​

  • Status: Implemented
  • Feature: 10 PrometheusRules with runbook_url annotations pointing to /runbooks/<alert>; orbital diag collects a diagnostics tarball with PII redaction default-on.
  • Evidence: Runbooks; Operations > Observability.

A.5.25 Assessment and decision on information security events ​

  • Status: Configurable
  • Feature: Structured logs publish err_code for every operation outcome; SIEM recipes (Loki / Elastic / Splunk) ingest the canonical schema so triage queries are copy-paste.
  • Evidence: Operations > Structured logs > SIEM setup.

A.5.26 Response to information security incidents ​

  • Status: Configurable
  • Feature: Security blocks (/api/admin/security) accept sha256 / path-glob / cve / repo expressions for immediate scope-down; webhook fan-out delivers OnBlocked events to incident channels; geo-sync failover endpoints (/api/admin/geo/peers/{id}/flip) promote a standby instance.
  • Evidence: Admin > Security > Blocks; Concepts > Security blocks.

A.5.27 Learning from information security incidents ​

  • Status: Configurable
  • Feature: audit_events and security_audit retain block history beyond the live block lifecycle; backup verification logs retain 90 days.
  • Evidence: /api/admin/audit?since=…; Admin > Backup verification.

A.5.28 Collection of evidence ​

  • Status: Implemented
  • Feature: Append-only audit tables (audit_events, security_audit, artifact_pulls, retention_audit, promotion_audit, backup_verification_runs, geosync_apply_audit); request_id correlation across handlers, workers, and DB lines.
  • Evidence: Operations > Structured logs.

A.5.29 Information security during disruption ​

  • Status: Implemented
  • Feature: Geo-sync push/pull/apply replicates governance state to a peer instance; /api/admin/geo/peers/{id}/flip switches active/standby. CloudNativePG primary-replica failover is automatic.
  • Evidence: Disaster recovery; Admin > Geo-sync.

A.5.30 ICT readiness for business continuity ​

  • Status: Implemented
  • Feature: Weekly backup-verification CronJob restores into an ephemeral CNPG cluster, runs the smoke suite, and emits the orbitalreg_backup_verification_last_success_timestamp Prometheus metric; OrbitalRegBackupStale alerts at >8 days.
  • Evidence: Backup verification; Runbooks > OrbitalRegBackupStale.
  • Status: Customer-side
  • Feature: Per-project license-compliance dashboard, CycloneDX 1.5 SBOM export, and CVE policy gates produce the artefacts customers cite for NIS2 / EU Cyber Resilience Act / SBOM-per-build obligations.
  • Evidence: Admin > License compliance; /api/v1/projects/{id}/build-info/{name}/{number}/sbom.

A.5.32 Intellectual property rights ​

  • Status: Configurable
  • Feature: License-compliance policy blocks uploads that violate per-project allowed-licenses; trust bundles prevent re-distribution of unsigned third-party content.
  • Evidence: Admin > License compliance > Policy.

A.5.33 Protection of records ​

  • Status: Implemented
  • Feature: Audit tables exempt from retention sweeper; CNPG backup retains 30 days of WAL + base backups; geo-sync mirrors audit events to a peer; soft-delete sends artifacts to a 30-day Trash before hard delete.
  • Evidence: Postgres on CloudNativePG; Concepts > Retention.

A.5.34 Privacy and protection of personal identifiable information ​

  • Status: Implemented
  • Feature: orbital diag PII redactor scrubs tokens / JWTs / emails / IPv4 / IPv6 / Authorization headers from diagnostic bundles by default; structured logs hash subject identifiers (oidc_sub_hash) rather than emit raw subjects.
  • Evidence: internal/diag/redact.go; Operations > Structured logs.

A.5.35 Independent review of information security ​

  • Status: Customer-side
  • Feature: OpenAPI 3.1 spec + Redoc explorer let an external auditor reproduce control assertions against the live API; backup verification logs are exportable as evidence.
  • Evidence: API explorer; Admin > Backup verification > Export.

A.5.36 Compliance with policies, rules and standards for information security ​

  • Status: Configurable
  • Feature: Slug naming convention (item 62) enforced at handler and surface in admin banner for legacy non-compliant slugs; pull-gate policies enforce CVE / license / scan policies at pull.
  • Evidence: Naming conventions; Admin > Pull-gate.

A.5.37 Documented operating procedures ​

  • Status: Implemented
  • Feature: Runbooks for the 10 PrometheusRules, disaster-recovery procedure, postgres-cnpg restore, backup-verification operator guide, structured-logs SIEM recipes — all versioned in this docs site and deployed alongside the binary.
  • Evidence: Runbooks; Operations.

A.6 — People controls (8) ​

People controls are mostly Customer-side — they sit with HR, training, and the disciplinary process — but OrbitalReg surfaces the technical hooks each one usually depends on.

A.6.1 Screening ​

  • Status: Customer-side

A.6.2 Terms and conditions of employment ​

  • Status: Customer-side

A.6.3 Information security awareness, education and training ​

  • Status: Customer-side
  • Feature: OrbitalReg ships a docs site with format-by-format guides so the practitioner half of awareness training is covered in-product.
  • Evidence: Guide; Formats.

A.6.4 Disciplinary process ​

  • Status: Customer-side

A.6.5 Responsibilities after termination or change of employment ​

  • Status: Configurable
  • Feature: Service-account tokens decoupled from human users so termination of a human account doesn't break CI; revocation API invalidates a token in <1s without a deploy.
  • Evidence: /api/v1/projects/{p}/service_accounts/{id}/tokens/ {tid}/revoke.

A.6.6 Confidentiality or non-disclosure agreements ​

  • Status: Customer-side

A.6.7 Remote working ​

  • Status: Customer-side
  • Feature: SSO with MFA at the IdP layer (Entra / Okta / Keycloak)
    • cookie / token expiry covers the technical access half.
  • Evidence: Admin > Authentication.

A.6.8 Information security event reporting ​

  • Status: Configurable
  • Feature: OnBlocked and OnFinding webhook events fan out to ChatOps channels; orbital diag produces a vendor-shareable bundle for downstream IR teams.
  • Evidence: Admin > Webhooks; orbital diag --output.

A.7 — Physical controls (14) ​

Physical controls are Customer-side: they apply to the data centre or cloud provider running OrbitalReg, not to the registry binary itself. The list below is included for completeness so a Statement-of-Applicability can cite this page for every Annex A control without exception.

ControlTitleNotes
A.7.1Physical security perimetersCustomer-side
A.7.2Physical entryCustomer-side
A.7.3Securing offices, rooms and facilitiesCustomer-side
A.7.4Physical security monitoringCustomer-side
A.7.5Protecting against physical and environmental threatsCustomer-side
A.7.6Working in secure areasCustomer-side
A.7.7Clear desk and clear screenCustomer-side
A.7.8Equipment siting and protectionCustomer-side
A.7.9Security of assets off-premisesCustomer-side
A.7.10Storage mediaCustomer-side — see A.8.10 (storage erasure) for the OrbitalReg-side mechanism.
A.7.11Supporting utilitiesCustomer-side
A.7.12Cabling securityCustomer-side
A.7.13Equipment maintenanceCustomer-side
A.7.14Secure disposal or re-use of equipmentCustomer-side — see A.8.10.

A.8 — Technological controls (34) ​

A.8.1 User end point devices ​

  • Status: Customer-side

A.8.2 Privileged access rights ​

  • Status: Implemented
  • Feature: admin role required for /api/admin/*; promotion of the first SSO sign-in to org-admin is one-shot and auditable; pull-gate / sigstore-policy / security-block CRUD all gated.
  • Evidence: audit_events filtered by event LIKE 'admin.%'.

A.8.3 Information access restriction ​

  • Status: Implemented
  • Feature: Per-repo visibility (public / internal / private), per-project role bindings, and per-token scope bundles compose to a least-privilege grant.
  • Evidence: Architecture > Identity.

A.8.4 Access to source code ​

  • Status: Configurable
  • Feature: Source-code-style artifacts (Helm charts, OCI images, Maven sources jars, npm tarballs) follow the same RBAC + scoped- token model as binary artifacts.
  • Evidence: Repo settings > Visibility.

A.8.5 Secure authentication ​

  • Status: Implemented
  • Feature: SAML 2.0 with signed assertions; OIDC with PKCE; OIDC token-exchange for CI workloads (no long-lived PATs); session cookie Secure / HttpOnly / SameSite=Lax.
  • Evidence: Admin > Authentication; API getting started.

A.8.6 Capacity management ​

  • Status: Configurable
  • Feature: Per-project storage quotas; Prometheus capacity metrics (orbitalreg_storage_bytes, scan-queue depth, retention deletions); load-test harness (tests/load/) plus Small/Medium/Large/XL sizing tables; high-disk-usage alert.
  • Evidence: Admin > Quotas; Performance; Runbooks > OrbitalRegHighDiskUsage.

A.8.7 Protection against malware ​

  • Status: Implemented
  • Feature: Detection workers (Trivy / Grype / OSV) scan every upload; pull-gate engine blocks artifacts that match worst- severity policy; security blocks accept sha256 / path-glob / cve patterns for immediate-effect quarantine.
  • Evidence: Concepts > Scanning; Admin > Pull-gate.

A.8.8 Management of technical vulnerabilities ​

  • Status: Implemented
  • Feature: Continuous re-scan as upstream feeds update; auto-quarantine on new CVE matching in-registry sha256; per-project quarantine threshold; OSV egress channel (allow_osv_lookups) toggleable in air-gapped mode.
  • Evidence: /api/v1/detection/findings; Admin > System > Egress.

A.8.9 Configuration management ​

  • Status: Implemented
  • Feature: Numbered SQL migrations applied at boot; /health/ready blocks until applied; OpenAPI spec drift CI gate; Terraform provider + Kubernetes operator (7 CRDs) for declarative governance config.
  • Evidence: api/internal/db/migrations/; Operator > CRD reference; Reference > Terraform provider.

A.8.10 Information deletion ​

  • Status: Implemented
  • Feature: Soft-delete sends artifacts to a 30-day Trash; hard-delete removes the row and S3 object; retention sweeper emits retention_audit rows; orbital seed --reset cleans demo data; CNPG pg_dump and Barman base backups expire after their configured retention.
  • Evidence: Concepts > Retention; retention_audit table.

A.8.11 Data masking ​

  • Status: Implemented
  • Feature: orbital diag PII redactor masks tokens, JWTs, emails, IPs, and Authorization headers in diagnostic bundles before they leave the cluster; structured logs hash OIDC subjects (oidc_sub_hash).
  • Evidence: internal/diag/redact.go; Operations > Structured logs.

A.8.12 Data leakage prevention ​

  • Status: Configurable
  • Feature: Per-repo visibility, per-token scope bundles, pull- gate policies that block based on artifact metadata, and air- gapped mode (default-off egress for webhooks / OSV / Sigstore / OTel / service pings).
  • Evidence: Air-gapped mode; Admin > System > Egress.

A.8.13 Information backup ​

  • Status: Implemented
  • Feature: CloudNativePG + Barman + S3 backup target produces daily base backups + continuous WAL; 30-day PITR window; weekly verification job restores and runs the smoke suite; OrbitalReg BackupStale alert at >8 days.
  • Evidence: Postgres on CloudNativePG; Backup verification.

A.8.14 Redundancy of information processing facilities ​

  • Status: Configurable
  • Feature: CNPG primary + replica; geo-sync push/pull replicates governance state to a second instance; failover-flip endpoint promotes a standby in one click.
  • Evidence: Disaster recovery; Admin > Geo-sync.

A.8.15 Logging ​

  • Status: Implemented
  • Feature: Structured JSON logs to stdout via internal/applog; canonical schema (component, request_id, principal_id, project_id, repo_id, latency_ms, err_code); make lint-logs CI gate forbids log.Printf; SIEM ingestion recipes for Loki / Elastic / Splunk; request_id propagates handler → workers → DB lines.
  • Evidence: Operations > Structured logs.

A.8.16 Monitoring activities ​

  • Status: Implemented
  • Feature: Prometheus /metrics (per-handler counters / histograms, scan queue depth, retention deletions, security-block hits, webhook duration / failures, backup-verification timestamp); ServiceMonitor CRD; three Grafana dashboards; OpenTelemetry tracing via OTLP/HTTP (off by default).
  • Evidence: Operations > Observability.

A.8.17 Clock synchronization ​

  • Status: Customer-side
  • Feature: OrbitalReg expects host clock to be NTP-synced; CloudNativePG + Postgres timestamps are UTC; structured logs emit RFC 3339 with offset.
  • Evidence: Operator's NTP / chrony configuration.

A.8.18 Use of privileged utility programs ​

  • Status: Configurable
  • Feature: orbital seed --reset, orbital diag, and orbital check are CLI utilities authenticated against an admin token; orbital seed is air-gapped-blocked unless --force is passed by an admin.
  • Evidence: Reference > orbital CLI.

A.8.19 Installation of software on operational systems ​

  • Status: Implemented
  • Feature: Helm chart + Kubernetes operator for declarative install; numbered SQL migrations applied at boot; helm upgrade rolls forward CRD schema; CNPG image catalog mirror gives an air-gapped customer a curated upgrade path.
  • Evidence: Operator > Installation; Admin > CNPG catalog.

A.8.20 Networks security ​

  • Status: Configurable
  • Feature: Air-gapped mode default-on for fresh installs; per- channel egress toggles (allow_outbound_webhooks, allow_osv_lookups, allow_sigstore_rekor, allow_otel_export, allow_service_pings, per-repo remote.allow_egress); HTTPS enforcement on webhook URLs.
  • Evidence: Air-gapped mode; Admin > System > Egress.

A.8.21 Security of network services ​

  • Status: Configurable
  • Feature: TLS via NGINX Ingress + cert-manager; OrbitalReg CertExpiring alerts at <14 days; webhook URLs validated as https:// at CRUD; geo-sync apply uses signed bearer tokens.
  • Evidence: Runbooks > OrbitalRegCertExpiring; Installation guide.

A.8.22 Segregation of networks ​

  • Status: Customer-side
  • Feature: OrbitalReg honours per-channel egress toggles so the operator can enforce network segregation at the registry layer in addition to network-policy controls at the cluster layer.
  • Evidence: Air-gapped mode.

A.8.23 Web filtering ​

  • Status: Customer-side

A.8.24 Use of cryptography ​

  • Status: Implemented
  • Feature: TLS 1.2+; SAML signed assertions; OIDC ID-token signature verification; HMAC SHA-256 on outbound webhooks; CMS / OpenPGP / RSA / Sigstore-cosign verify-on-pull; SigV4 signing inline for the AWS CodeArtifact importer; service-account JWT signature for OIDC token-exchange.
  • Evidence: Concepts > Trust bundles; Admin > Trust; Admin > Sigstore policies.

A.8.25 Secure development life cycle ​

  • Status: Customer-side
  • Feature: OrbitalReg ships SBOM-per-build, build-info reverse lookup, and pull-gate so the operator's SDLC has the artefacts it needs.
  • Evidence: Concepts > Build-info.

A.8.26 Application security requirements ​

  • Status: Customer-side

A.8.27 Secure system architecture and engineering principles ​

  • Status: Implemented
  • Feature: Single-binary architecture with pluggable backends (Postgres / Redis / S3); air-gapped-by-default posture; numbered migrations; OpenAPI drift gate; numerical-UID Dockerfile so the binary can run under PodSecurity baseline.
  • Evidence: Architecture; Dockerfile.

A.8.28 Secure coding ​

  • Status: Customer-side

A.8.29 Security testing in development and acceptance ​

  • Status: Implemented
  • Feature: Integration test suite (35 reference formats), CI drift gate on OpenAPI spec, make lint-logs log-shape gate, load-test harness (k6); release artefacts cosign-signed.
  • Evidence: tests/, .github/workflows/.

A.8.30 Outsourced development ​

  • Status: Customer-side

A.8.31 Separation of development, test and production environments ​

  • Status: Configurable
  • Feature: Per-instance OrbitalReg deployments with geo-sync as optional bridge; demo-data seeder is air-gapped-blocked so it cannot accidentally populate a production install.
  • Evidence: Admin > Geo-sync; Admin > Seed.

A.8.32 Change management ​

  • Status: Implemented
  • Feature: Numbered SQL migrations with up/down semantics; /health/ready blocks until applied; OpenAPI spec drift CI gate; Terraform provider exposes every resource for declarative config- as-code; audit_events records every admin write.
  • Evidence: api/internal/db/migrations/; .github/workflows/verify-openapi.yml.

A.8.33 Test information ​

  • Status: Configurable
  • Feature: orbital seed populates a curated test set (projects / repos / SAs / blocks) with --set minimal | default | full; reset purges test data; air-gapped guard prevents accidental seeding of production.
  • Evidence: Admin > Seed; Reference > orbital CLI.

A.8.34 Protection of information systems during audit testing ​

  • Status: Configurable
  • Feature: Read-only admin role planned; in-app API playground (item 64 Phase D) is admin-toggle gated and disabled by default in production to prevent self-DDoS; orbital diag produces an evidence bundle without touching live config.
  • Evidence: Admin > API reference (toggle); orbital diag.

Statement-of-Applicability template ​

Most ISO 27001 audits begin with a Statement-of-Applicability (SoA) that lists every Annex A control, its inclusion status, and the justification. The mapping above is structured so you can copy each control row directly into your SoA spreadsheet:

Annex A refTitleApplicable?OrbitalReg statusEvidence link
A.5.7Threat intelligenceYesImplemented/api/v1/detection/findings
A.5.15Access controlYesImplementedAdmin > API tokens
A.5.30ICT readiness for business continuityYesImplementedBackup verification page
A.8.13Information backupYesImplementedBackup verification page
A.8.15LoggingYesImplementedOperations > Structured logs
A.8.20Networks securityYesConfigurableOperations > Air-gapped mode
A.8.24Use of cryptographyYesImplementedAdmin > Trust
A.8.32Change managementYesImplementedverify-openapi CI workflow

Append your other rows from the body of this page; the Status column maps directly to the SoA "Justification for inclusion / exclusion" cell.

What this page does not do ​

  • It does not assert that a deployment is automatically ISO 27001-certified by virtue of running OrbitalReg. Certification is granted against the customer's ISMS by an accredited body; the registry is one technical control source among many.
  • It does not replace your auditor's independent verification. Use this page to short-cut the what does the product do? conversation, then have the auditor reproduce the assertions from the cited APIs and admin pages.
  • It does not map the management-system clauses (4–10) of ISO 27001:2022. Those describe how the ISMS is run — leadership commitment, risk treatment, performance evaluation — and sit entirely with the customer.

Released under the Apache-2.0 License.

Copyright © 2025 OrbitalReg contributors. Documentation built with VitePress.