Scrydon
Compliance

ISO/IEC 27001

How Scrydon controls map to ISO/IEC 27001:2022 — the information security management baseline most enterprises require.

ISO/IEC 27001 is the international standard for information security management. This page maps Scrydon's controls to ISO 27001:2022 Annex A and notes what evidence the platform produces automatically.

Scope

ISO 27001 is organisational. Scrydon implements the technical controls that satisfy the Annex A requirements relevant to a hosted enterprise application. The customer still owns the surrounding management-system controls — policies, risk treatment plans, internal audit, management review.

This page covers what Scrydon delivers. Pair it with your organisation's ISMS documentation for the full picture.

Annex A coverage

A.5 Organisational controls

ControlScrydon support
A.5.10 Acceptable use of informationPlatform usage is governed by audit + ToS.
A.5.15 Access controlThree-tier permission hierarchy. See Permission model.
A.5.18 Access rights provisioningSCIM-driven provisioning + audit. See Identity & Provisioning.
A.5.23 Cloud services securityCustomer-deployed model means controls live in your cluster. See Architecture.

A.8 Technological controls

ControlScrydon support
A.8.2 Privileged access rightsOrg-owner / admin tiers are first-class. Every privileged action audited.
A.8.3 Information access restrictionColumn masking, row filters, document clearance. See Classification & masking.
A.8.5 Secure authenticationSSO via Microsoft Entra, Okta, OneLogin; MFA via the IdP. See Identity & Provisioning.
A.8.7 Protection against malwareFile-upload AV-scanning for knowledge-base ingestion.
A.8.10 Information deletionPer-org delete + configurable retention. See GDPR → Right to erasure.
A.8.11 Data maskingPer-column mask strategies. See Classification & masking.
A.8.12 Data leakage preventionGuardrails block, redaction on logs and exports. See DLP and Redaction.
A.8.15 LoggingStructured audit log with retention. See Audit logging.
A.8.16 Monitoring activitiesAudit log + SIEM forwarding.
A.8.20 Network securityService mesh with mTLS, explicit egress, ingress hardening. See Network boundary.
A.8.22 Segregation of networksEach subsystem runs in its own namespace with Dapr ACLs.
A.8.24 Use of cryptographyTLS 1.2+ at ingress, mTLS internal, AES at rest.
A.8.25 Secure development life cycleSigned Helm charts, signed images, SBOM. See Deployment.
A.8.26 Application security requirementsServer-issued execution grants, Rego authorisation. See Authorization.
A.8.28 Secure codingInternal CI gates + code review enforced through harness.

Evidence the platform produces

Evidence typeWhere it livesUsed for
Audit logAudit endpoint + SIEM forwarderA.5.7, A.8.15, A.8.16
Access reviewsSCIM provisioning logsA.5.18
Mask strategy reportsAnalytics governance UIA.8.3, A.8.11
Encryption configurationHelm values + secret managerA.8.24
Network policyHelm egress configA.8.20, A.8.22
SBOMRelease artefactsA.8.25
Vulnerability reportsImage scanner outputA.8.8

Vanta automation

If you use Vanta, the platform supports automatic evidence collection for:

  • A.5.15, A.5.18 — access reviews via SCIM logs.
  • A.8.15, A.8.16 — log evidence via the audit forwarder.
  • A.8.24 — TLS posture via the ingress endpoint scan.
  • A.8.25 — SBOM via the release manifest endpoint.

Manual evidence (organisational policies, training records, management review minutes) lives outside the platform.

  • ISO 42001 — AI-specific counterpart.
  • SOC 2 — overlaps significantly with 27001's technical controls.
  • Security — every link above resolves to a specific control page.
On this page

On this page