ISO 27001 Annex A Controls

A 5.1

Policies for information security 

We operate an ISO 27001:2022-certified ISMS (Information Security Management System). We maintain a top-level Information Security Policy and supporting topic-specific policies (incident management, physical security, supplier security, ethics, AI, and others), approved by management and reviewed at least annually. Policies are communicated internally via onboarding, annual awareness training. Relevant PUBLIC and BUSINESS CONFIDENTIAL versions are shared with clients and partners on request, please see https://trust.safeture.com/policies-and-documents

A 5.2

Information security roles and responsibilities

Security governance is led by a Security Steering Group (SSG) comprising the DPO and Information Security Manager (ISM), with overall accountability from the CEO. Team leads own resources, processes, onboarding/offboarding, and compliance within their areas. Roles and responsibilities for business continuity and operations are documented and aligned to ISO 27001 organizational controls. Records of training, skills, experience, and qualifications is kept in our ISMS.

For more information see Information Security Policy and Business Continuity Plan https://trust.safeture.com/policies-and-documents

A 5.3

Segregation of duties

To reduce the risk of possible errors and unallowed intentional actions segregation is implemented, that means that no single employee alone has control over a critical actions, e.g. push updates to the production environment, approve a background check or sign a policy.

For more information see Information Security Policy and SSDLC https://trust.safeture.com/policies-and-documents

A 5.4

Management responsibilities

Executive management endorses information security, sets measurable objectives (including platform availability and limits on security incidents), and reviews ISMS performance twice a year. Local deviations from the Information Security Policy are not permitted; breaches may trigger disciplinary action.

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents https://www.safeture.com/terms-of-service/

A 5.5

Contact with authorities

Where required by law or contract, we coordinate with supervisory authorities and regulators through the DPO and Security Steering Group (SSG). Incident communication procedures include notifying affected clients and, where applicable, relevant authorities in line with GDPR and other privacy legislations.

For more information see Incident Management Policy https://trust.safeture.com/policies-and-documents https://www.safeture.com/terms-of-service/

A 5.6

Contact with special interest groups

We maintain structured external engagement channels for security and compliance input, including legal advisors across relevant jurisdictions, standards and best-practice sources (for example ISO/NIST/OWASP guidance), and supplier-facing governance forums. Input from these channels is fed into policy reviews, risk assessments, and management reporting to keep controls aligned with emerging requirements.

For more information see Risk Management Policy and Work Instruction https://trust.safeture.com/policies-and-documents https://www.safeture.com/terms-of-service/

A 5.7

Threat intelligence

We use layered security monitoring with a 24/7 on-duty security team to investigate anomalous behavior. Asset and risk owners continuously evaluate threats and vulnerabilities per ISO/IEC 27005.

For more information see Incident Management Policy https://trust.safeture.com/policies-and-documents

A 5.8

Information security in project management

Security is integrated into administration, projects, and product development. Engineering follows a Secure Software Development Lifecycle (SSDLC) with OWASP-focused training, secure frameworks, code review, and separation of environments. Changes to production follow documented change and approval processes before release.

For more information see Information Security Policy and SSDLC https://trust.safeture.com/policies-and-documents

A 5.9

Inventory of information and other associated assets

Critical assets are recorded in our ISMS asset inventory with appointed asset and risk owners. Inventories are reviewed continuously and at least yearly, with threat, vulnerability, and risk scores used to define risk treatment plans. Our inventory is the basis for risk assessment and control selection in our Statement of Applicability.

For more information see Information Security Policy and Statement of Applicability https://trust.safeture.com/policies-and-documents

A 5.10

Acceptable use of information and other associated assets

All personnel must follow documented work instructions and policies on acceptable use, confidentiality, and protection of information—whether working on premises or remotely. Activities in sensitive information systems are monitored. Unacceptable use (e.g. unauthorized disclosure, misuse of integrations) is prohibited and may result in disciplinary action.

For more information see Information Security Policy, NDA, Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 5.11

Return of assets

Onboarding and offboarding processes include assignment and revocation of access rights and return of the company-owned assets (e.g. laptops, access cards and information systems). Team leads and SSG (Security Steering Group) assist in ensuring access is removed promptly on termination or role change, with activities logged in our on/off-boarding records.

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents

A 5.12

Classification of information

Personal data processed for clients is according to our DPA classified as Class A (sensitive, e.g. passport, medical) or Class B (less sensitive), with stronger controls for Class A. Suppliers are classified A–D depending on data processed. Corporate and operational information is classified per our internal classification model referenced in policies.

For more information see Supplier Security Policy https://trust.safeture.com/policies-and-documents and https://trust.safeture.com/personal-data-classification

A 5.13

Labelling of information

Our classification approach covers labelling, handling, transfer, storage, retention, and secure disposal of information. Client-facing personal data classes are published online; supplier and internal classifications guide how data may be stored, transmitted, and shared with subprocessors.

For more information see Supplier Security Policy https://trust.safeture.com/policies-and-documents and https://trust.safeture.com/personal-data-classification

A 5.14

Information transfer

All data sent to or from us is encrypted in transit (HTTPS/TLS 1.2+). Transfers outside the EU/EEA follow GDPR requirements, including Standard Contractual Clauses with subprocessors where applicable. Clients may use Personal Data Localization or configuration options to limit transfers. Integrations (SSO, HR, travel data) are documented in our System Overview.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents and https://trust.safeture.com/personal-data-classification

A 5.15

Access control

Access to our platform is governed by SAML SSO, role-based access controls (end-user, local admin, super admin, country admin, etc.), optional IP whitelisting, and strong authentication. Production systems use least privilege, need-to-know access, MFA, frequently audited, continuously monitored, and is controlled by our Operations Team. A restricted group of SecDevOps personnel has access to the Safeture production, the group also monitor accesses to the environment using LGTM-stack.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents

A 5.16

Identity management

Clients may use SAML SSO with common identity providers (Azure AD, Okta, OneLogin, Google Workspace, and others). User provisioning can be supported via HR integrations, APIs, or SFTP, as described in our integration documentation. Admin and end-user identities are managed per client configuration with unique accounts.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents

A 5.17

Authentication information

Where SSO is not used, passwords are hashed with PBKDF2 and meets complexity rules (minimum length, mixed case, numbers). Password hashes are not stored for SSO-only clients. Administrators have two-factor authentication enabled by default (app push, email, or SMS). Hosting and corporate systems also require MFA and strong password policies.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents

A 5.18

Access rights

Access is granted on a least-privilege, need-to-know basis and reviewed on joiners, movers, leavers, and periodically reviews for privileged and personal accounts where applicable. Only authorized personnel belonging to Client Development, Support, Operations, and Product may access client data, to be able to support the service. Clients control admin roles within the platform via RBAC.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents

A 5.19

Information security in supplier relationships

Suppliers are risk-classified (A–D). Class A subprocessors processing sensitive client data must hold ISO/IEC 27001:2022 certification and a GDPR-compliant DPA/SCCs. Data processed, classification, asset owner, and the contract itself is kept in the register. Security reviews are performed before engagement and monitored ongoing.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents https://trust.safeture.com/personal-data-and-subprocessors and https://www.safeture.com/terms-of-service/ DPA

A 5.20

Addressing information security within supplier agreements

Contracts and DPAs require subprocessors to meet the same data protection the same data protection obligations we maintain, including security measures, breach notification, access limitations, and deletion of data at contract end.

For more information see System Overview, Information Transfer Policy https://trust.safeture.com/policies-and-documents https://trust.safeture.com/personal-data-and-subprocessors and https://www.safeture.com/terms-of-service/ Section DPA

A 5.21

Managing information security in the ICT supply chain

We identify critical components in our ICT supply chain (hosting, email, integrations) and apply heightened scrutiny when services are built or operated outside our company, including where top-tier suppliers subcontract. Hosting is limited to vetted Swedish ISO 27001-certified providers.

For more information see System Overview and Supplier security Policy https://trust.safeture.com/policies-and-documents, https://trust.safeture.com/personal-data-and-subprocessors, https://www.safeture.com/terms-of-service/ Section DPA

A 5.22

Monitoring, review and change management of supplier services

Supplier security is reviewed before use and monitored for compliance. Sub-processor lists are published and updated with advance notice. Asset owners manage contract renewal and ensure data removal from suppliers, including backups, when contracts terminate. Security reviews are performed before engagement and monitored ongoing.

For more information see System Overview and Supplier security Policy https://trust.safeture.com/policies-and-documents, https://trust.safeture.com/personal-data-and-subprocessors, https://www.safeture.com/terms-of-service/ Section DPA

A 5.23

Information security for use of cloud services

We are a SaaS provider. Production is hosted in Sweden in ISO/IEC 27001-certified data centers (EcoDataCenter, itm8/AddPro); We are manage operations from the OS level upward, including network design, hardening, patching, and monitoring. Data is not subject to the US Cloud Act when hosted in Sweden.

For more information see System Overview and Supplier Security Policy https://trust.safeture.com/policies-and-documents, https://trust.safeture.com/personal-data-and-subprocessors, https://www.safeture.com/terms-of-service/ Section DPA

A 5.24

Information security incident management planning and operation

A formal Incident Management Policy defines how events, weaknesses, and nonconformities are reported, assessed, escalated, and resolved. Staff report to the SSG (Security Steering Group); critical incidents engage analysis and communication teams. Incidents are tracked in Jira with defined impact ratings and linkage to BCP/DRP where needed.

For more information see Incident Management Policy https://trust.safeture.com/policies-and-documents, https://www.safeture.com/terms-of-service/ Section DPA

A 5.25

Assessment and decision on information security events

The SSG (Security Steering Group); performs initial evaluation of reported events and decides when they become incidents. Examples range from documented minor nonconformities to major service or data-impacting events. Inconclusive cases trigger an Incident Analysis Team to determine scope and impact before wider response.

For more information see Incident Management Policy https://trust.safeture.com/policies-and-documents, https://www.safeture.com/terms-of-service/ Section DPA

A 5.26

Response to information security incidents

Incident response includes containment, remediation, internal and external communication, and client notification aligned with the DPA (personal data breach notice within 48 hours of awareness, with ongoing updates until resolution). A 24/7 security and operations capability supports service-affecting events.

For more information see Incident Management Policy, Business Continuity Plan and Disaster Recovery Plan https://trust.safeture.com/policies-and-documents, https://www.safeture.com/terms-of-service/ Section DPA

A 5.27

Learning from information security incidents

Incidents and significant events are documented, reviewed for root cause, and used to drive corrective actions, ISMS improvements, and updates to controls. Lessons learned feed into BCP/DR testing, policy reviews, and management review. Minor incidents are tracked to stay within defined quarterly thresholds.

For more information see Incident Management Policy and Information Security Policy https://trust.safeture.com/policies-and-documents, https://www.safeture.com/terms-of-service/ Section DPA

A 5.28

Collection of evidence

Where investigations may require forensic evidence, strict procedures apply under Internal Audit and SSG (Security Steering Group) guidance to preserve integrity of logs and systems. Collection is approached carefully to support potential legal or disciplinary follow-up without compromising other controllers' data.

For more information see Incident Management Policyhttps://trust.safeture.com/policies-and-documents

A 5.29

Information security during disruption

Business Continuity and Disaster Recovery plans address how we continue or restores operations during incidents and crises. The CEO has overall responsibility for BCP; incident response may invoke DRP or BCP when data or services are materially affected.

For more information see Information Security Policy, Business Continuity Plan and Disaster Recovery Plan https://trust.safeture.com/policies-and-documents

A 5.30

ICT readiness for business continuity

Infrastructure and data are distributed across two Swedish data centers so service can continue if one site fails. DR is tested regularly through planned exercises, with clear role assignments, activation criteria, and event logging during recovery operations. Backups with automated integrity checks runs every night, monitored for service-impacting events alerting/escalation to our operations team. We commit to 99.95% monthly availability, with defined maintenance windows and SLA credits if targets are missed.

For more information see Information Security Policy, Business Continuity Plan and Disaster Recovery Plan https://trust.safeture.com/policies-and-documents https://www.safeture.com/terms-of-service/ Section SLA

A 5.31

Legal, statutory, regulatory and contractual requirements

We align with GDPR, CCPA (where applicable), Swedish law, and contractual commitments in the Terms, DPA, and Subscription Agreement. Regulatory developments are tracked (e.g. via OneTrust Data Guidance). Clients remain controllers for employee/user data; We act as processor under the DPA.

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents https://www.safeture.com/terms-of-service/ https://www.safeture.com/non-compliance-list/

A 5.32

Intellectual property rights

Intellectual property in our Services, platform, and app remains with us or our licensors, as set out in the Terms of Use. Clients receive a limited license to use the service; users must not reverse-engineer or misuse software except where law requires otherwise.

https://www.safeture.com/terms-of-service/

A 5.33

Protection of records

We maintain GDPR Article 30 processing records and apply defined retention in the DPA: personal data retained while the subscription is active and up to 18 months after it ends (or shorter if the client request a shorter retention option).

https://www.safeture.com/terms-of-service/ Section DPA

A 5.34

Privacy and protection of PII

We process personal data as processor under the DPA and client instructions. We provide a privacy policy for users, it has to be accepted when the account is created. End users control location privacy in the app.

Our DPO can be reached dpo@safeture.com. Data subject request support via the client.

Class A data is not transferred outside EU/EEA unless expressly instructed. Both our Information Security Management System (ISMS) and (PIMS) Privacy framework (PIMS) is based on the ISO27001 standard.

https://www.safeture.com/terms-of-service/ Section DPA and Privacy Policy

A 5.35

Independent review of information security

We and key hosting providers are ISO/IEC 27001 certified. In scope of our certification we are externally audited on an annual basis. Clients may request DPIA summaries, penetration test executive summaries, and audit reports under the NDA.

https://trust.safeture.com/certificates For more information see Statement of Applicability https://trust.safeture.com/policies-and-documents

A 5.36

Compliance with policies, rules and standards

Compliance is checked through regular policy reviews, internal and external audits, management review, and monitoring of ISMS objectives. Employees must follow policies; violations may lead to disciplinary action or prosecution where criminal offences are suspected.

For more information see Information Security Policy, Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 5.37

Documented operating procedures

ISMS documentation includes policies, work instructions, BCP/DRP, SSDLC practices, on/off-boarding records, and operational runbooks. Documentation is reviewed at least annually (or more often for some topics) updates could also be triggered by  audits, incidents, organizational changes and legal changes.

For more information see Information Security Policy and Work Instruction https://trust.safeture.com/policies-and-documents

A 6.1

Screening

Background checks are performed for all new employees including identity verification, employment verification, criminal checks, credit checks, references, education verification, and related checks used in our standard screening package. Personnel with access to client data may be re-screened periodically (e.g. every three years).

For more information see Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 6.2

Terms and conditions of employment

Employment agreements and our Business Ethics Policy define security, confidentiality, acceptable conduct, and consequences for breaches. Employees are expected to apply ethical standards in dealings with clients, suppliers, and colleagues across all our operations.

For more information see Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 6.3

Information security awareness, education and training

All employees complete security and awareness training at onboarding and at least annually. Role-specific training is provided for security, DPO, and team leads.

For more information see Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 6.4

Disciplinary process

A formal disciplinary process applies when employees breach information security or ethics policies, in line with employment agreements. Serious breaches may be referred for criminal prosecution.

For more information see Information Security Policy and Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 6.5

Responsibilities after termination or change of employment

On termination or role change, team leads and SSG (Security Steering Group) ensure access rights are revoked promptly, assets are returned, and on/off-boarding checklists are completed. Production/client-data access is removed in line with least-privilege principles.

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents

A 6.6

Confidentiality or non-disclosure agreements

All employees sign NDAs and the Business Ethics Policy, covering confidential information of ours, clients, and partners. Confidentiality obligations survive employment and align with how we protect client data as processor.

For more information see Business Ethics Policy https://trust.safeture.com/policies-and-documents

A 6.7

Remote working

The same information security requirements apply for remote work as on site; conditions and expectations are reinforced in annual awareness training. Remote access uses corporate security controls (SSO, MFA, zero-trust-oriented network, encrypted devices).

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents

A 6.8

Information security event reporting

All staff must report security events, suspected incidents, or nonconformities to the Security Steering Group without delay. Anonymous reporting is supported. Developers and operations have additional reporting paths for technical events, with escalation if SSG (Security Steering Group) does not acknowledge high-impact reports within one hour.

For more information see Incident Management Policy https://trust.safeture.com/policies-and-documents

A 7.1

Physical security perimeters

Our Lund headquarters uses physical entry controls; production client data resides in ISO 27001-certified Swedish data centers with their own perimeter controls. We review datacenter physical security policies and Statement of Applicability.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.2

Physical entry

HQ access is restricted to authorized individuals via a digital access system, with access logs retained at least one month. Datacenter access is permit-based, role-limited, and logged.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.3

Securing offices, rooms and facilities

Secure areas (e.g. server rooms at HQ where applicable) have additional locks and role-based access. Visitors are escorted and by default denied access to secure areas and confidential data locations. Facilities are kept clean and tidy with cable management for safety and security.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.4

Physical security monitoring

Physical entry control systems at our facilities monitor and log access. Datacenter providers actively monitor physical access, fire/smoke alarms, and environmental controls 24/7 with trained response procedures.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.5

Protection against physical and environmental threats

Datacenters must be ISO 27001-certified; we request their physical security policy and SoA before acceptance. Controls address fire, power (UPS/generators), environmental monitoring, theft, and vandalism at hosting sites; HQ follows documented physical security rules.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/personal-data-and-subprocessors

A 7.6

Working in secure areas

Only personnel whose roles require it may access secure areas; contractors and visitors are escorted and managed. Access to areas hosting or viewing sensitive data is minimized and aligned with RBAC at both office and datacenter levels.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.7

Clear desk and clear screen

Work instructions and information transfer requirements include practical clear-desk and clear-screen behaviors. Personnel are instructed not to leave sensitive information visible, to handle written/printed material according to confidentiality level, and to follow secure ways of working in office and remote settings. These requirements are reinforced through recurring awareness activities and role-based responsibilities.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.8

Equipment siting and protection

Equipment is positioned to reduce unauthorized viewing of sensitive information. Information processing facilities handling sensitive data are placed to limit exposure. Storage facilities for physical records or media are secured against unauthorized access.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.9

Security of assets off-premises

Off-premises work is subject to the same rules as on-site work. Company laptops are encrypted; removable media use is restricted by policy. Employees must protect access credentials and not leave confidential material exposed when working remotely.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.10

Storage media

Use of removable media is prohibited by policy. When equipment is reused or disposed of, data is securely removed or overwritten (e.g. laptops). Physical media handling at datacenters is governed by provider controls under certification.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.11

Supporting utilities

Hosting providers supply resilient power (UPS, diesel generators) and environmental controls appropriate to tier-class facilities.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.12

Cabling security

Cable management practices apply in secure areas at HQ. Datacenter cabling security is provided by certified hosting providers per their physical security programs.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.13

Equipment maintenance

Servers and infrastructure are maintained and patched through centralized configuration management (Ansible), with security baselines monitored via Prometheus and logging. Supported software versions only are used in production. Critical maintenance is communicated per SLA terms.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 7.14

Secure disposal or re-use of equipment

Procedures require secure disposal or overwrite before equipment reuse. Removable media is not permitted, reducing disposal risk from portable storage. Asset inventory tracks hardware and supports controlled retirement of devices.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 8.1

User endpoint devices

Corporate workstations use ESET Endpoint Security with up-to-date malware scanning of files, downloads, and web/email traffic. Endpoints connect through a zero-trust-oriented corporate network with firewall filtering.

A 8.2

Privileged access rights

Production access is limited to a restricted SecDevOps group using MFA and least privilege. Privileged accounts are identified, reviewed periodically (including on role changes), and monitored through logging. Security components (SIEM, firewalls) are similarly restricted to authorized personnel.

https://trust.safeture.com/data-protection-measures

A 8.3

Information access restriction

Platform RBAC defines what partners, client super admins, group admins, and end users can create, view, edit, or delete—including locations, PNRs, chat, analytics, and country information—as documented in the System Overview access matrix.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.4

Access to source code

The platform is developed in-house in Sweden. All code changes require mandatory peer review before promotion to production. Annual independent penetration tests include source code review by external security experts; clients may run their own tests.

For more information see SSDLC https://trust.safeture.com/policies-and-documents

A 8.5 

Secure authentication

Client admins use 2FA by default (unless SSO is enabled). Corporate and hosting access uses SAML SSO, MFA, and strong passwords. Production management interfaces are protected with certificates and MFA. Mobile apps use additional encryption beyond TLS where applicable.

For more information see System Overview https://trust.safeture.com/data-protection-measures

A 8.6

Capacity management

Service availability is measured monthly with a commitment of at least 99.95% uptime, monitored by third-party synthetic checks of critical subsystems. Capacity and performance are managed across dual datacenters; scheduled and critical maintenance follow defined notice periods in the SLA.

For more information see https://www.safeture.com/terms-of-service/ Section SLA

A 8.7

Protection against malware

ESET protects endpoints and servers with continuous scanning. Email and web traffic are filtered at endpoints; office pfSense firewalls block untrusted sites and malicious traffic. Server and network layers are included in monitoring and vulnerability management.

A 8.8

Management of technical vulnerabilities

Vulnerabilities are managed through SSDLC practices, Dependabot for dependencies/CVEs, Ansible-driven patching (test → staging → production), and annual third-party penetration tests plus source code review. Findings are prioritized in Jira and remediated by severity.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 8.9

Configuration management

Security configuration baselines for Rocky Linux systems are defined and deployed centrally via Ansible, with current configuration reported through Prometheus and centralized logging. Baselines align with OWASP, NIST, and CIS Benchmark practices used by engineering.

For more information see Physical Security Policy https://trust.safeture.com/policies-and-documents

A 8.10

Information deletion

On contract end or instruction, personal data is returned, deleted, or anonymized per the DPA, including backups when no legal retention applies. Configurable retention (default 18 months) and automatic user/data deletion options are available in the platform.

For more information see https://www.safeture.com/terms-of-service/ Section DPA and Privacy Policy

A 8.11

Data masking

Usage analytics use pseudonymization before processing. Development, test, and staging use auto-generated mock data only—never production client data.

For more information see https://www.safeture.com/terms-of-service/ Section DPA and Privacy Policy

A 8.12

Data leakage prevention

DLP is addressed through policy and technical measures: removable media prohibited, annual awareness training, network filtering (pfSense), port controls, and classification-based handling. Organizational controls are reinforced even where full DLP tooling is not deployed on every endpoint.

For more information see Information Security Policy https://trust.safeture.com/policies-and-documents

A 8.13

Information backup

Nightly automated backups with post-backup integrity testing; backups are stored separately from production and include encrypted recovery paths. Recovery procedures define restore workflows, accountable roles, and retrieval via 24/7 operational support when needed. DR design supports 24-hour RPO/RTO across geographically separated facilities.

For more information see Disaster Recovery Plan and System Overview https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.14

Redundancy of information processing facilities

Production runs across two Swedish data centers (EcoDataCenter, itm8) with failover and cold/warm DR design so operations continue if one site fails. Network and processing redundancy are part of platform architecture (Classic and NextGen stacks).

For more information see Disaster Recovery Plan and System Overview https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.15

Logging

Application audit logs capture client admin and internal admin actions. Infrastructure and security logs are shipped to a central log platform (LGTM stack) designed to resist tampering by ordinary privileged users. Production console and application actions are logged, and disaster recovery execution includes a structured event log with time-stamped key actions and handover records.

For more information see Audit & Monitoring Policy and System Overview https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.16

Monitoring activities

Multi-layer monitoring detects anomalous behaviour; alerts escalate to 24/7 operations, network, and security coverage. Quarterly manual log review plus automated alarms support detection of invalid access attempts and operational issues.

For more information see Incident Management Policy and System Overview https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.17

Clock synchronization

All servers use a reliable external time source (http://pool.ntp.org ) so security logs across systems can be correlated accurately for investigations and audit.

For more information see Audit & Monitoring Policy and System Overview https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.18

Use of privileged utility programs

Use of privileged administrative tooling is restricted to authorized roles and controlled through formal access management, least privilege, and approval workflows. Privileged and administrative activity is logged and monitored via centralized auditing and monitoring controls, with review responsibilities assigned to security and operations roles. Operational runbooks for recovery and platform administration include controlled privileged command execution (for example sudo-based actions), with traceability through ticketing and event logs.

For more information see Audit & Monitoring Policy and Disaster Recovery Plan https://trust.safeture.com/policies-and-documentshttps://trust.safeture.com/data-protection-measures

A 8.19

Installation of software on operational systems

Production software installation and changes occur only through controlled release and change processes: patches flow test → staging → production via Ansible; unauthorized local installation on servers is prevented by operational standards

For more information see Access Control Policy and Audit & Monitoring Policy https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.20

Networks security

Architecture uses a DMZ, ACLs on virtual datacenters, and deny-by-default firewall rules for external connectivity. Only secured protocols (TLS 1.2+) are permitted; telnet/FTP and similar are not allowed. Network diagrams and flows are documented in the System Overview.

For more information see System Overview https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.21

Security of network services

External services expose TLS 1.2+ endpoints (SSL Labs A+ rated). ISP-level DDoS protection and application-level rate limits on APIs protect availability. Management access uses certificates and MFA; IP allowlisting is available for client admin access.

For more information see https://trust.safeture.com/data-protection-measures https://www.safeture.com/terms-of-service/ DPA and Privacy Policy

A 8.22

Segregation of networks

Networks are logically segmented (DMZ, internal application tiers, databases, external integrations). Traffic between zones is filtered; wireless at HQ is segregated from corporate LAN and provides general internet only.

For more information see System Overview https://trust.safeture.com/policies-and-documents

A 8.23

Web filtering

Office pfSense firewalls block untrusted sites and filter packages. Endpoint anti-malware adds web/mail scanning. Together these reduce drive-by and malicious download risks for staff systems.

For more information see https://trust.safeture.com/data-protection-measures

A 8.24

Use of cryptography

TLS 1.2+ in transit with strong cipher suites, HSTS, and perfect forward secrecy; AES-256 at rest for stored data. Mobile applications add an extra encryption layer for app API traffic. Cryptographic key practices are defined in SSDLC and work instructions.

For more information see System Overview https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.25

Secure development life cycle

Engineers follow SSDLC with annual secure coding training (OWASP Top 10), secure open-source frameworks, dedicated QA and application security review, and security requirements tied to data sensitivity before development starts.

For more information see SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.26

Application security requirements

Security requirements are identified for applications based on sensitivity of data processed (Class A/B) and platform functionality. Input validation, framework controls, and error handling follow NIST/OWASP-aligned practices documented in development standards.

For more information see SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.27

Secure system architecture and engineering principles

Documented Classic and NextGen architectures, cloud-native microservices migration, defense-in-depth hosting, zero-trust-oriented corporate access, and published System Overview for clients describe security boundaries and data flows.

For more information see System Overview and SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.28

Secure coding

Secure coding standards reduce exposure to OWASP Top 10 risks (SQLi, XSS, CSRF, etc.). Mandatory code review precedes production deployment; Dependabot monitors dependencies for license and CVE issues.

For more information see SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.29

Security testing in development and acceptance

QA tests releases; security testing includes vulnerability scanning and annual external penetration tests and code review. Security is explicitly tested before go-live; critical findings are tracked to closure in Jira.

https://trust.safeture.com/data-protection-measures

A 8.30

Outsourced development

Core platform development is performed in-house by our staff in Sweden; we do not outsource primary application development. Third-party components and libraries are vetted (e.g. Dependabot, trusted sources.

For more information see System Overview and SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.31

Separation of development, test and production environments

Four environments—production, staging, manual test, and development—are logically and physically separated. No client production data is used outside production; lower environments use generated mock data only.

For more information see System Overview and SSDLC https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.32

Change management

Changes follow a documented process with requester/approver segregation, impact assessment, testing in non-production, and approval before production promotion. Security-impacting changes include documented configuration requirements, code review checkpoints, and controlled deployment activities to reduce operational risk. Maintenance windows aim to minimize client impact per SLA.

For more information see SSDLC https://trust.safeture.com/data-protection-measures https://www.safeture.com/terms-of-service/ Section SLA

A 8.33

Test information

Test and staging environments use autogenerated dummy data only. Sanitized or production copies are not used for development or QA, eliminating test-data leakage of client PII.

For more information see System Overview https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures

A 8.34

Protection of information systems during audit testing

Clients may audit DPA compliance subject to notice, confidentiality, and safeguards that protect other clients and We operations. We provide ISO certificate, SoA, public policies, and on-request DPIA/pentest summaries per DPA section 2.3.23.

For more information see Statement of Applicability https://trust.safeture.com/policies-and-documents https://trust.safeture.com/data-protection-measures https://www.safeture.com/terms-of-service/ Section DPA