ALLOD | Trust Center

Annex A controls

ISO/IEC 27001:2022 control list

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).	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.	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.	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.	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.	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 (govuln, cargo audit) and manual review in CI/CD pipeline. Private bug bounty program provides continuous adversarial testing by external researchers.	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

Product controls

Per-product security controls

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.

ALLOD | SWG

Secure Web Gateway

a.8.5 SWG enforces authenticated access; integrates with identity providers for user-based policy.
a.8.7 SWG blocks known malware and offensive-tooling indicators via JA3/JA4/JARM fingerprint matching against known C2 frameworks (Cobalt Strike, Sliver, Meterpreter, and others), and detects disguised executables via magic-byte file-type/extension mismatch.
a.8.8 SWG binary is built with dependency pinning and automated vulnerability scanning in CI pipeline.
a.8.15 SWG produces structured audit logs of all proxied requests including user, URL, policy decision, and timestamps.
a.8.16 SWG exposes metrics and logs for integration with monitoring and SIEM systems.
a.8.20 SWG is the network security enforcement point; admin interfaces are not exposed to the internet.
a.8.23 SWG enforces domain/URL category filtering and real-time threat-intelligence lookups (MISP) to block access to malicious and non-compliant websites.
a.8.24 SWG performs full TLS inspection using AES-256; customer CA keys are managed under customer control.

ac-4 SWG enforces information flow policy via domain/category/IP/region firewall rules and DLP content rules (filename, body, entropy, PII/PCI patterns) rather than default-allow.
ac-4.4 TLS interception (dynamic per-host leaf certificates signed by a locally generated root CA) lets AC-4 flow-control policy apply to encrypted traffic, not just plaintext.
sc-7 SWG is the sole network egress enforcement point; all HTTP/1.1, HTTP/2, HTTP/3, and SMTP/SMTPS/STARTTLS traffic is proxied and evaluated against firewall and DLP policy before reaching its destination.
sc-7.8 All monitored egress traffic is routed through the SWG forward proxy; known public DoH resolvers are forced through inspection so DNS-layer proxy bypass is not possible.
sc-7.10 DLP content rules and DNS-exfiltration heuristics (query entropy, label/FQDN length, query rate) block or alert on data leaving via HTTP, SMTP, SaaS chat APIs, DNS, clipboard-correlated uploads, and removable media.
si-4 TLS/HTTP/SSH client and TLS server fingerprinting (JA4, JA4H, HASSH, JARM), DGA detection, and typosquat detection continuously monitor connections for malicious or anomalous indicators.
si-4.18 A dedicated DNS-exfiltration detector scores every DNS query on label entropy, label/FQDN length, record type, and per-apex query rate to catch covert-channel tunneling independent of any single signature.
si-3 JA4 and JA3 fingerprint lookups identify known C2 frameworks (Cobalt Strike, Sliver, Meterpreter, and others) and malware families; file-type/extension mismatch detection catches executables disguised with a benign extension.
au-13 The DLP engine inspects outbound content across web upload/download, SMTP/webmail, SaaS chat APIs, clipboard-to-file correlation, and removable media for indicators of unauthorized disclosure, including regulated data patterns (payment card numbers, IBAN, national ID numbers). For certificate-pinned hosts, where the exception path means no content is ever inspected, a rate-limited live query to the agent checks for a currently open, previously-tagged sensitivity file as a compensating alert-only signal - a lookup against files already flagged elsewhere, not a fresh scan of new content.
mp-7 A cross-platform agent hook (Windows, Linux, macOS) inspects file writes to USB and other removable volumes through the same DLP rule engine used for network egress, and can block the write.
ra-10 Live traffic (domain, IP, JA3, JARM, JA4, User-Agent, URI, filename, SHA-256, port) is continuously checked against MISP and static OSINT threat-intelligence feeds.
ac-2 SaaS account/identity resolution attributes observed SaaS actions to real accounts; shared-account detection flags any non-IdP personal-tier account used by three or more employees as an unsanctioned or shared credential.
ac-20 CASB tenant restriction extracts and enforces an allow-list of organizational SaaS tenants per application, and can block personal-tier accounts outright.
sc-8 SMTP, SMTPS, and STARTTLS sessions are intercepted and inspected before delivery; a certificate-pinning exception path narrowly and temporarily relaxes inspection only for the specific host and duration needed to keep pinned applications functional.
ac-17 ZTNA access-control rules default-deny raw TCP CONNECT to internal CIDR:port destinations, scoped by device, user, and group, unless explicitly allowed.
ir-4 Indicators generated by SWG's own detections (fingerprint blocklists, threat feeds, DGA and typosquat blocks) are exported to CrowdStrike Falcon as custom prevent-IOCs.
ca-7 Device compliance/posture signal (external MDM pass, fail, or unknown) is evaluated as a live condition on both firewall and DLP rules, not only at enrollment time.

cis-13.5 Firewall and DLP rules can require a live external MDM/posture signal (pass, fail, or unknown) before allowing a connection or content flow, tying enforcement to known, managed devices.
cis-3.3 CASB tenant restriction applies access-control-list-style enforcement to SaaS applications: it allow-lists approved organizational tenants per application and blocks personal-tier accounts outright.
cis-3.12 ZTNA access-control rules default-deny raw TCP CONNECT to internal CIDR:port destinations unless explicitly allowed, segmenting which internal systems a given device, user, or group can reach.
cis-3.13 A DLP rule engine inspects filename, content-type, body content, and entropy across web upload/download, SMTP/webmail, SaaS chat APIs, clipboard-to-file correlation, removable media, and transfer-size policy, with built-in detectors for regulated data patterns and AI-assisted content classification as a second opinion. Certificate-pinned hosts, otherwise fully exempt from content inspection, still get a live compensating check against files already tagged by that rule engine elsewhere - it cannot flag content it has never seen before.
cis-4.1 Certificate-pinning exceptions are handled as a narrow, time-limited configuration override (24 hours, specific host) rather than a blanket policy change, and device posture is treated as a live configuration input to policy rather than a one-time enrollment check.
cis-4.9 Admin-configured DNS servers can be scoped to an internal zone (split DNS) or forced for every query, routing DNS resolution through enterprise-designated servers instead of whatever the OS already has configured.
cis-5.1 SaaS account resolution attributes observed SaaS actions to real accounts; shared-account detection flags any non-IdP personal-tier account used by three or more employees; SCIM sync pulls IdP group membership into the same account picture.
cis-6.1 Accounts and tenants used outside the normal IdP-governed access-granting process - unsanctioned personal-tier accounts shared across employees - are surfaced automatically rather than relying on manual review.
cis-6.7 SaaS account resolution and CASB tenant restriction give a single, centralized enforcement point for which SaaS accounts and tenants are permitted, independent of each SaaS application's own native access controls.
cis-6.8 Pulled IdP group membership acts as an AND-condition on both firewall and DLP rules, letting policy be scoped by role or group rather than by individual user.
cis-9.2 DNS queries are scored for exfiltration risk (entropy, label/FQDN length, query rate), algorithmically-generated domains are flagged, known public DoH resolvers are forced through inspection rather than allowed to bypass it, and static OSINT feeds contribute additional domain-level indicators.
cis-9.3 Domain and URL-based policy (category, glob, AI-assisted fallback categorization, and typosquat/lookalike detection) is enforced at the network layer for every HTTP/1.1, HTTP/2, HTTP/3, and SaaS chat API request, including detection of credential submission to lookalike or unapproved destinations.
cis-9.6 Filename-based DLP rules match against every email attachment name, not just the message itself, closing what would otherwise be a silent bypass for file-type policy on the email channel.
cis-3.13 SMTP, SMTPS, and STARTTLS sessions are intercepted and the full message body is inspected and can be blocked by the DLP engine before the message is allowed to proceed to delivery, extending DLP enforcement to email as an active blocking point rather than passive monitoring.
cis-10.1 Client TLS fingerprints are checked against a database of known offensive-framework fingerprints (Cobalt Strike, Sliver, Meterpreter, and others), and live traffic indicators are continuously checked against MISP threat-intelligence feeds.
cis-10.7 Magic-byte detection identifies when a file's real type contradicts its declared extension or Content-Type - a behavioral check that catches disguised executables regardless of whether a specific malware signature exists for them.
cis-12.2 Internal network reachability is governed by an explicit-allow access model (default-deny raw TCP CONNECT to internal CIDR:port destinations) rather than a flat, implicitly-trusted internal network.
cis-13.8 TLS, HTTP, and SSH client fingerprints (JA4, JA4H, HASSH) and TLS server fingerprints (JARM) are usable as live block conditions on both firewall and DLP rules, not just passive logging.
cis-13.10 Firewall policy operates at the application layer (domain, category, IP, region, and TLS/HTTP fingerprint), and TLS interception extends that filtering to encrypted traffic rather than stopping at the TCP/IP layer.
cis-13.11 Fingerprint- and indicator-based detections (JA4DB, SSLBL, MISP, and static OSINT threat feeds) are evaluated per-connection against continuously updated indicator sets rather than a fixed, unmaintained blocklist.
cis-14.2 Credential-harvest detection acts as a technical backstop to security-awareness training, flagging when a corporate credential or a typosquat/lookalike destination is involved in a login-form submission regardless of whether the employee recognized the phishing attempt.
cis-13.1 Indicators generated by the gateway's own detections (fingerprint blocklists, threat feeds, DGA and typosquat blocks) are exported to CrowdStrike Falcon as custom prevent-IOCs, centralizing gateway-generated security events into the broader EDR/security-alerting stack for correlation.

ALLOD | DAM

Digital Asset Management

a.5.9 DAM maintains an inventory of tracked vendor systems and their security-relevant assets.
a.5.22 DAM facilitates continuous security monitoring of supplier relationships through automated OSCAL probing and trust scoring.
a.5.21 DAM imports and tracks SBOM data (SPDX, CycloneDX) from vendors to surface supply-chain risks.
a.8.5 DAM's admin UI requires OIDC/SSO federation (or a local password fallback) before granting access, and service-to-service calls (e.g. from allodswg) are authenticated with a rotatable per-customer bearer token.
a.8.3 DAM enforces per-tenant isolation, restricting each tenant's data and API access to its own scope.

Security posture, open by design.

Annex A control coverage

ISO/IEC 27001:2022 control list

Per-product security controls

ALLOD | SWG

ALLOD | DAM

OSCAL component definition

Component definition

Canonical URL

Verifiable supply chain

CycloneDX SBOM

Open source

Release feed

Your infrastructure, your data

Swedish incorporation, no US parent

License server only

Responsible disclosure

See it run in your environment.