Allod publishes its ISO 27001 control implementation as machine-readable OSCAL so that procurement teams and auditors can verify our security posture without asking us first.
The following controls are in scope for the Allod Solutions AB ISMS, covering ISO/IEC 27001:2022 and the EU Cyber Resilience Act. Status reflects the current implementation as published in the OSCAL System Security Plan.
| Control | Description | Status |
|---|---|---|
| a.5.1 | Mandatory per ISO 27001. Information security policy established. | Implemented |
| a.5.2 | Roles and responsibilities defined in the information security policy, allocated to named individuals across CEO, CTO, CISO and DevOps roles. | Implemented |
| a.5.3 | Full personnel SoD is not possible in a single-person company. Technical compensating controls are implemented: signing keys reside exclusively in the build server (inaccessible from developer workstations), the build fails automatically on known vulnerabilities so signing never occurs, and all signing events are logged. Residual risk is documented and accepted by management (R-02). | Implemented |
| a.5.4 | Management has an explicit commitment to the ISMS per the information security policy. | Implemented |
| a.5.5 | Relevant for security incidents and GDPR reporting to the supervisory authority (IMY). Also covers EU Cyber Resilience Act Article 14 reporting of actively-exploited vulnerabilities and severe incidents to the relevant CSIRT / ENISA single reporting platform (24h early warning, 72h notification, 14-day final report), mandatory from 2026-09-11. | Implemented |
| a.5.6 | Relevant for threat landscape monitoring, e.g. CERT-SE. | Implemented |
| a.5.7 | Monitoring supply-chain threats and vulnerabilities in dependencies. | Implemented |
| a.5.8 | Security must be considered in product development from the outset. | Implemented |
| a.5.9 | Asset inventory is part of the risk assessment. | Implemented |
| a.5.10 | Rules for handling source code, certificates and production systems. | Implemented |
| a.5.11 | Relevant upon termination of employment - access to the Git instance, pipeline and certificates must be revoked. | Implemented |
| a.5.12 | Information classified as Public, Internal or Confidential. | Implemented |
| a.5.13 | Documents and code must be labelled according to the classification scheme. | Implemented |
| a.5.14 | Communication with customers and the licence server must be encrypted. | Implemented |
| a.5.15 | Least privilege applied to all systems within scope. | Implemented |
| a.5.16 | All user accounts must be personal and traceable. | Implemented |
| a.5.17 | Password policy and MFA requirements for all systems within scope. | Implemented |
| a.5.18 | Access rights reviewed regularly and revoked when no longer needed. | Implemented |
| a.5.19 | Hosting providers and certificate providers are in scope. | Implemented |
| a.5.20 | Security requirements must be included in contracts with hosting providers. | Implemented |
| a.5.21 | Supply-chain risks managed via SBOM and dependency scanning. | Implemented |
| a.5.22 | Security levels of hosting providers reviewed regularly. | Implemented |
| a.5.23 | All hosting is with Swedish providers - security requirements must be specified. | Implemented |
| a.5.24 | Incident handling process required to fulfil the commitment to proactive communication. | Implemented |
| a.5.25 | Classification of incidents for correct escalation and communication. | Implemented |
| a.5.26 | Procedures for handling and remedying incidents. | Implemented |
| a.5.27 | Incidents must lead to improvements in the ISMS. | Implemented |
| a.5.28 | Logging and evidence handling for security incidents. | Implemented |
| a.5.29 | Business continuity planning for the licence server and critical infrastructure. | Implemented |
| a.5.30 | Technical readiness to restore critical systems following a disaster. | Implemented |
| a.5.31 | GDPR, ISO 27001, customer contracts and code-signing provider requirements. | Implemented |
| a.5.32 | Source code and product constitute intellectual assets that must be protected. | Implemented |
| a.5.33 | Documentation and logs must be protected against unauthorised access and loss. | Implemented |
| a.5.34 | GDPR compliance for personal data in communication. | Implemented |
| a.5.35 | Internal audit of the ISMS at least once per year. | Implemented |
| a.5.36 | Compliance with this SoA and the information security policy is monitored. | Implemented |
| a.5.37 | Procedures for operating the licence server, pipeline and mail server must be documented. | Implemented |
| a.6.1 | Background checks for personnel with access to critical systems. | Implemented |
| a.6.2 | NDAs and security responsibilities must be included in employment contracts. | Implemented |
| a.6.3 | All staff must receive training in information security, phishing and social engineering. | Implemented |
| a.6.4 | Consequences for breaching security policies must be defined. | Implemented |
| a.6.5 | Access to all systems revoked immediately upon termination of employment. | Implemented |
| a.6.6 | NDAs signed with all staff. | Implemented |
| a.6.7 | Security requirements for remote work - encrypted connection, disk encryption. | Implemented |
| a.6.8 | Procedures for staff to report suspected incidents. | Implemented |
| a.7.1 | Applicable to the hosting provider's data centre - security requirements to be included in contracts. | Implemented |
| a.7.2 | Access control to data centres managed by the hosting provider - verified via contracts and audits. | Implemented |
| a.7.3 | Physical equipment located at a third-party data centre. Physical security of the facility is enforced via DC contract and the DC's own certifications. No office premises. | Implemented |
| a.7.4 | Surveillance and physical security monitoring at the data centre managed by the DC operator - verified via contract and audits. | Implemented |
| a.7.5 | Fire suppression, climate control and physical threat protection managed by the DC operator - requirements specified in contract. | Implemented |
| a.7.6 | Only authorised personnel may access the data centre. No external visits permitted. Physical access logged by the DC operator. | Implemented |
| a.7.7 | Staff must lock screens and handle physical documents securely. | Implemented |
| a.7.8 | Staff workstations must be protected against unauthorised access. | Implemented |
| a.7.9 | Laptops and mobile devices must be protected with disk encryption and passwords. | Implemented |
| a.7.10 | External storage media used for backup must be encrypted. | Implemented |
| a.7.11 | Power supply and network connectivity for the hosting provider's data centre - requirements in contracts. | Implemented |
| a.7.12 | Physical equipment located at a third-party data centre. Cabling security enforced via DC contract and weekly visual inspection of cabling by authorised personnel. | Implemented |
| a.7.13 | Maintenance of staff workstations - updates and patching. | Implemented |
| a.7.14 | Secure erasure of data when disposing of workstations. | Implemented |
| a.8.1 | Disk encryption, up-to-date software and MFA on all workstations. | Implemented |
| a.8.2 | Administrative access to the licence server and Git instance strictly limited. | Implemented |
| a.8.3 | Access to source code, secrets and production systems restricted to authorised personnel. | Implemented |
| a.8.4 | Access to the Git repository controlled via branch protection and role-based permissions. | Implemented |
| a.8.5 | MFA required on all systems within scope. | Implemented |
| a.8.6 | Licence server capacity monitored to ensure availability. Allod SWG's proxy and controller API additionally rate-limit connection attempts lacking valid credentials - including a cross-source tier for floods distributed across many source addresses - so such traffic cannot exhaust processing capacity needed for legitimate use. | Implemented |
| a.8.7 | Antivirus protection and automated vulnerability scanning in the pipeline. | Implemented |
| a.8.8 | Dependencies pinned and scanned; servers and workstations patched. Externally, a public coordinated vulnerability disclosure policy (SECURITY.md / security.txt per RFC 9116) and a published minimum 5-year security-update support period exist per product; fixed vulnerabilities are disclosed as CSAF 2.0 advisories at /.well-known/csaf/. Driven in part by the EU Cyber Resilience Act's vulnerability-handling requirements (Annex I Part II) and Article 14 incident/vulnerability reporting obligation (mandatory from 2026-09-11). | Implemented |
| a.8.9 | Infrastructure configuration version-controlled and reviewed. | Implemented |
| a.8.10 | Secure erasure of data when decommissioning systems or equipment. | Implemented |
| a.8.12 | Source code and certificates must not be able to leak via external services. Allod SWG is deployed internally to enforce web filtering and DLP policies on outbound traffic. | Implemented |
| a.8.13 | Automated mirroring of the Git repository and backup of licence server data. | Implemented |
| a.8.14 | Existing installations continue to operate without the licence server (graceful degradation). Recovery from backup per backuprutin within documented RTO. | Implemented |
| a.8.15 | Audit logging enabled on the Git instance, licence server and mail server. | Implemented |
| a.8.16 | Logs reviewed regularly to detect anomalies. Rate-limiter trigger counts are tracked per surface and reported via Slack/Teams once a sustained threshold is crossed, rather than left to manual log review alone. | Implemented |
| a.8.17 | All systems must use NTP for consistent log timestamps. | Implemented |
| a.8.18 | Administration tools for servers and pipeline managed with strict permissions. | Implemented |
| a.8.19 | Only approved software installed on production systems. | Implemented |
| a.8.20 | Administration interfaces not exposed to the internet; network segmentation applied. Internet-exposed endpoints (Allod SWG's proxy and agent-facing API, licence server, allod.solutions admin routes) hold unauthenticated connections and close them only after a bounded delay rather than reject them immediately, so flood tooling cannot use a fast rejection as a retry signal. | Implemented |
| a.8.21 | Security requirements for network services at the hosting provider specified in contracts. | Implemented |
| a.8.22 | Production and development environments must be separated. | Implemented |
| a.8.23 | Web filtering enforced centrally via Allod SWG deployed internally. | Implemented |
| a.8.24 | Encryption in transit (TLS) for licence server communication; AES-256 in the product. | Implemented |
| a.8.25 | Security integrated into the development process - review, testing and scanning in the pipeline. | Implemented |
| a.8.26 | Security requirements defined for the licence server and product. | Implemented |
| a.8.27 | Security principles applied in design of the licence server and product architecture. | Implemented |
| a.8.28 | Secure coding guidelines applied and reviewed via pull requests. | Implemented |
| a.8.29 | Automated vulnerability scanning (govulncheck, cargo audit, and Trivy container-image scanning against the build-time SBOM) and manual review in CI/CD pipeline. No bug bounty program exists yet - coordinated vulnerability disclosure is handled via the public contact form (see SECURITY.md / security.txt in each product repository). | Implemented |
| a.8.31 | Development and production must be separated environments. | Implemented |
| a.8.32 | All changes to source code and infrastructure managed via the standard change management process in the Git instance. | Implemented |
| a.8.33 | Production data not used in test environments. | Implemented |
| a.8.34 | Bug bounty program operates with defined scope and rules of engagement that prohibit production disruption, data destruction and DoS. | Partial |
| annex-i-part-i-a | No known exploitable vulnerabilities at market - govulncheck (Go) and cargo audit (Rust/Android) run in CI on every push across all Allod products; Trivy scans the build-time CycloneDX SBOM for every container image and blocks the push (not just the CI job) on any CRITICAL or HIGH finding. | Implemented |
| annex-i-part-i-b | Secure by default configuration, with reset capability - Each product ships secure-by-default: e.g. Allod SWG's ZTNA and firewall policy default-deny (explicit-allow model), and allodctl ca --regenerate / the agent's --clean flow restore a device or CA to a known clean state. | Implemented |
| annex-i-part-i-c | Vulnerabilities addressable via security updates, automatic where appropriate, with notification and opt-out/postpone - The fleet admin operating agents via the controller's "Agent upgrade" tab is the relevant "user" for a centrally-managed security gateway, not each individual device. Automatic rollout exists (auto_update_agents, default off - an uncontrolled automatic update to inline traffic-inspection code is a bigger operational risk than a delayed patch for this product) with a manual "Upgrade all" opt-out alternative; the controller now proactively notifies the admin via Slack/Teams when a new agent version becomes available, and a postpone control (POST /api/admin/agent-upgrade-postpone) lets the admin delay an automatic rollout by N hours without disabling it. | Implemented |
| annex-i-part-i-d | Protection from unauthorised access, with reporting - Role-scoped API keys and OIDC/SSO sessions across products, with MFA delegated to the customer's IdP where applicable; every login, auth failure, and config change is written to an audit log. | Implemented |
| annex-i-part-i-e | Confidentiality of stored/transmitted data - TLS for all agent/controller and admin-UI traffic; AES-256-GCM at rest for DLP-related secrets and vault-stored credentials, with per-secret HKDF-derived keys rather than one static key. | Implemented |
| annex-i-part-i-f | Integrity of data/commands/programs/configuration, with corruption reporting - Config changes are audit-logged and Postgres-backed under Allod SWG's Controller HA (no silent divergence between replicas). Every agent/ctl/server release artifact is Ed25519-signed by the license server and verified against a pinned public key before installation (internal/relsign), on top of the pre-existing SHA-256 checksum. | Implemented |
| annex-i-part-i-g | Data minimisation - DLP-alert-triggered full-content captures are deleted automatically after 24 hours (agent-side, hardcoded); event-store retention cleanup is a leader-gated background job under Controller HA, not indefinite accumulation. | Implemented |
| annex-i-part-i-h | Availability of essential functions, including after an incident - Controller HA (active/passive, Postgres-backed leader election and failover) keeps admin sessions and config current across a controller failure; existing agent/proxy installations continue enforcing their last-known policy even if the controller or license server is unreachable (graceful degradation). | Implemented |
| annex-i-part-i-i | Minimise negative impact on the availability of other devices or networks - Products' own outbound calls (threat-feed polling, license checks) are scheduled/interval-based rather than continuous, and are leader-gated under Controller HA so only one replica makes them, not one per replica. | Implemented |
| annex-i-part-i-j | Limit attack surface, including external interfaces - Server/proxy/connector container images build from a distroless base with CGO_ENABLED=0 static binaries where the Zeek/cgo build isn't in use; each product's exposed surface is a small, fixed set of ports rather than a broad service mesh. | Implemented |
| annex-i-part-i-k | Reduce the impact of an incident via exploitation-mitigation techniques - Go's memory safety rules out the exploitation-mitigation-relevant vulnerability classes (buffer overflow, use-after-free) that dominate this requirement for C/C++ products; Allod SWG's certificate-pinning exceptions are scoped to a single host and expire automatically within 24 hours rather than persisting. | Implemented |
| annex-i-part-i-l | Security-related information via recording and monitoring of internal activity - An append-only audit log records logins, auth failures, config changes, JIT/step-up access decisions, and content-inspector access, independent of the DLP/firewall event stream itself. | Implemented |
| annex-i-part-i-m | Secure and easy permanent removal of data and settings - allodctl ca --regenerate and the agent's --clean flow remove the installed CA and reset local trust/config state; secure erasure of decommissioned infrastructure is also documented in the ISO 27001 SoA (A.8.10). | Implemented |
| annex-i-part-ii-1 | Identify and document vulnerabilities and components, including a machine-readable SBOM - CycloneDX SBOMs are generated per binary (cyclonedx-gomod) and per container image (syft) for every Allod product, covering the full dependency graph, not just top-level dependencies - a stricter bar than Annex I Part II (1) itself requires. | Implemented |
| annex-i-part-ii-2 | Address and remediate vulnerabilities without delay; security updates separate from functionality updates where feasible - govulncheck/cargo-audit/Trivy findings are triaged per SECURITY-ADVISORY-PROCESS.md and fixed promptly (see the allodswg repository's own dependency-bump history). A documented severity/blast-radius classification and hotfix policy (product-vulnerability-severity-policy.md, allod-isms) commits Critical/High findings to an immediate out-of-band release rather than waiting for or bundling with unrelated feature work - satisfied through process discipline on a single release line rather than a parallel LTS/backport branch structure, which Annex I Part II (2)'s own "where technically feasible" qualifier doesn't mandate for a small team. | Implemented |
| annex-i-part-ii-3 | Apply effective and regular tests and reviews of product security - govulncheck, cargo audit, and Trivy run on every push in CI across all Allod products; all code changes go through pull-request review (ISO 27001 SoA A.8.28); test suites include real-Postgres and browser-driven end-to-end coverage, not unit tests alone. | Implemented |
| annex-i-part-ii-4 | Once a security update is available, publicly disclose fixed-vulnerability information (description, affected product, impact, severity, remediation) - Published as CSAF 2.0 documents at /.well-known/csaf/<id>.json (allodweb), validated against the official OASIS schema by cmd/validate-csaf before publication. | Implemented |
| annex-i-part-ii-5 | Put in place and enforce a coordinated vulnerability disclosure policy - SECURITY.md in each product repository (allodswg, allodweb, allodvrm) and /.well-known/security.txt (RFC 9116). | Implemented |
| annex-i-part-ii-6 | Facilitate information-sharing about potential vulnerabilities, including a reporting contact address - security.txt's Contact field and SECURITY.md both point to the public contact form; the published SBOM plus CSAF feed together let a customer assess their own exposure to a vulnerability in a third-party component Allod depends on. | Implemented |
| annex-i-part-ii-7 | Provide mechanisms to securely distribute updates, timely and automatically where applicable - Every agent/ctl/server download is Ed25519-signed by the license server (release.signing_key) and verified fail-closed against a pinned public key (internal/relsign) before it's ever written to its final path - a missing or invalid signature rejects the download outright. | Implemented |
| annex-i-part-ii-8 | Disseminate available security updates without delay, free of charge, with advisory messages - Security fixes ship in ordinary releases at no extra cost within an active license, and each CSAF advisory doubles as the advisory message describing remediation. | Implemented |
In addition to the organizational ISMS, each product implements specific controls from ISO/IEC 27001:2022, NIST SP 800-53, and CIS Controls v8 directly in its architecture.
Secure Web Gateway
Vendor Risk Management
Product capabilities and organizational compliance are published as separate, standards-based OSCAL documents. Import them into your GRC tool, feed them to Allod VRM, or verify them programmatically.
OSCAL 1.1.2 · v0.1
Per-product control implementations for Allod SWG and Allod VRM - claims your own system can inherit.
/.well-known/oscal/component-definition.jsonOSCAL 1.1.2 · v0.1
Allod Solutions AB's own ISO/IEC 27001:2022 ISMS control implementation, published as an OSCAL System Security Plan.
/.well-known/oscal/system-security-plan.jsonOSCAL 1.1.2 · v0.1
Every release ships with a software bill of materials covering all Go module dependencies.
Releases →Subscribe to the RSS feed to be notified of new releases and security advisories.
RSS →Security fixes for at least 5 years per release, or the product's remaining lifetime if shorter. Coordinated vulnerability disclosure via security.txt.
security.txt →Published as CSAF 2.0 (OASIS Common Security Advisory Framework) documents - machine-readable, one file per advisory.
No security advisories have been published to date.
No sub-processors by architecture.
ALLOD runs in infrastructure you control. Allod Solutions has no technical access to your traffic, event log, or policy - not by contract, but by architecture. There are no sub-processors to list because there is no data to process on your behalf.
Allod Solutions AB is incorporated in Sweden with no US parent entity - no CLOUD Act exposure through the vendor relationship.
The only contact between your deployment and Allod infrastructure is license validation and threat feed distribution - no traffic data, no event log, no policy.
Found a vulnerability? Use our contact form to send us details. We commit to an initial response within 2 business days.
Book a 30-minute demo. We'll walk through how ALLOD addresses your specific regulatory requirements.