Cloud Security
and Shared Responsibility Statement

1. Purpose and scope

ISO/IEC 27017 control CLD.6.3.1 requires that responsibilities for shared information security roles in the use of a cloud service are allocated to identified parties, documented, communicated and implemented by both the cloud service customer (CSC) and the cloud service provider (CSP). The control also requires the CSP to provide the customer with information about the information security capabilities of the cloud service and the measures the CSP has taken, so that the customer can understand them clearly and adequately. The control is carried forward unchanged in intent as clause 5.38 of the second edition, ISO/IEC 27017:2026.

This statement is how IDR Oy meets that obligation. It is the single customer-facing document that describes what IDR Oy secures, what Amazon Web Services secures beneath us, and what remains the customer’s responsibility. It also answers the other disclosure points that ISO/IEC 27017 places on the provider, listed in Annex A against both editions.

1.1 What this document covers

• The IDR System as delivered by IDR Oy and hosted on Amazon Web Services (AWS).
• Production and test environments operated by IDR Oy for the delivery of the service.
• The allocation of information security responsibilities between AWS, IDR Oy and the customer.

1.2 What this document is not

This statement is informational and describes IDR Oy’s security posture at the date of issue. It does not vary the Agreement or the Data Processing Agreement (DPA). Where this statement and a signed agreement differ, the signed agreement prevails. Contractual commitments, including personal data processing terms, breach notification obligations and audit rights, are set out in the DPA.

IDR Oy’s internal ISO 27017 supplement policies are classified Restricted and are not distributed. Section 2.4 lists the evidence that is available to customers on request instead. This statement describes controls and commitments rather than implementation detail; specific configuration, tooling and architecture are deliberately not published, as their disclosure would itself weaken the controls described.

2. Assurance and independent review

2.1 Certification

IDR Oy operates an information security management system certified to ISO/IEC 27001:2022 by an accredited certification body. The certification scope covers the entire lifecycle of IDR application development, covering planning, analysis, design, implementation, testing, deployment and maintenance, and applies to all employees, contractors and third-party providers involved in those activities, together with the information assets and infrastructure that support them.

The current certificate, including its number, issuing body, full scope statement and validity dates, is available on request. It is not reproduced here so that this statement does not need reissuing at each certification and surveillance cycle.

2.2 ISO/IEC 27017 cloud controls

IDR Oy has implemented the cloud service provider controls and guidance of ISO/IEC 27017 as a documented supplement to the certified ISO 27001 management system. The supplement is approved by IDR Oy management and reviewed at least annually and after material architecture change.

These controls are currently implemented and self-declared by IDR Oy, evidenced by the material listed in section 2.4. The external audit to extend IDR Oy’s certification to include ISO/IEC 27017 is under way, and this statement will be updated when that extension is issued.

2.3 Edition and transition position

The IDR Oy cloud control set is documented and assessed against ISO/IEC 27017:2015, the first edition, which uses the CLD.* control identifiers aligned to the ISO/IEC 27002:2013 control structure. This is the basis of the current assessment cycle.

ISO/IEC 27017:2026, the second edition, was published on 27 July 2026 and aligns the cloud guidance to the ISO/IEC 27002:2022 control structure used by ISO/IEC 27001:2022. IDR Oy has mapped its existing cloud control set to the second edition, and transition of the supplement policy references and the Statement of Applicability is planned.

The second edition introduces two controls with no equivalent in the first edition: clause 5.39, agreement on the roles and responsibilities of the cloud service partner, and clause 8.36, detection and prevention of unauthorized use of cloud services. Both are identified in the IDR Oy transition plan and are noted in this statement where relevant.

2.4 Independent review and evidence available to customers

ISO/IEC 27017 guidance on control 18.2.1 (second edition clause 5.35) provides that where individual customer audits are impractical or would themselves increase information security risk, the provider should offer independent evidence that its controls are implemented and operating, and should make that evidence available to prospective customers before contract. IDR Oy meets this through the following, available on request and subject to a confidentiality undertaking:

• The ISO 27001 certificate and its scope statement.
• A summary report from the most recent third-party penetration test, which carries the date on which it was performed.
• This statement and the ISO/IEC 27017:2026 disclosure map at Annex A.
• Completed security questionnaire responses.
• AWS assurance documentation references (AWS is certified to ISO/IEC 27001, 27017 and 27018 and publishes SOC reports through AWS Artifact).

Customer audit rights, notice periods and cost allocation are governed by the DPA rather than by this statement.

2.5 Assurance over sub-processors and cloud service partners

AWS assurance documentation and the assurance evidence of other critical third parties are reviewed at least annually as part of the critical vendor review tracked in the IDR Oy compliance calendar under the Third-Party Management Policy. IDR Oy additionally monitors the AWS Health Dashboard, AWS security bulletins and service advisories on an ongoing basis.

3. Service, jurisdiction and data location

ISO/IEC 27017 guidance on control 18.1.1 (second edition clause 5.31) requires the provider to tell the customer which legal jurisdictions govern the service and in which countries customer data and cloud service derived data can be stored and processed.

4. Shared responsibility model

Security of the IDR System is delivered jointly. AWS secures the cloud infrastructure. IDR Oy secures the IDR System running on it. The customer secures its own use of the service, its users and the accuracy of the data it submits. The matrix below is the control-by-control allocation.

4.1 Customer support relationship

ISO/IEC 27017:2026 expects the customer to identify and manage its relationship with the provider’s customer support function. IDR Oy provides support through its ticketing system; security matters may also be raised directly with the contacts in section 10.

5. Information security capabilities of the service

This section is IDR Oy’s disclosure of the capabilities and measures referred to in ISO/IEC 27017 control CLD.6.3.1 (second edition clause 5.38), together with the specific capability disclosures required elsewhere in the standard.

5.1 Identity, authentication and access control

• Application access is determined by authenticated user role, permitted company hierarchy, request scoping, query-level filtering and explicit permission checks.
• Federated single sign-on is available to customers as an option, allowing customer users to authenticate through the customer’s own identity provider and inherit its authentication and multi-factor policy.
• Administrative access to the cloud environment is provided through an approved enterprise identity provider that enforces multi-factor authentication as a prerequisite for login.
• Infrastructure access roles follow least privilege and are scoped to the resources each service component requires. Roles and policies are defined in version-controlled infrastructure as code.
• Privileged access to production infrastructure requires MFA through the approved identity provider and role-based access.
• Administrative access is approved by the asset owner, provisioned under the Access Control Policy, and reviewed at least quarterly; the review is recorded and confirmed at management review.
• Joiner, mover and leaver handling follows the Access Control Policy.
• Administrative credentials, secrets and service roles are held in an approved managed secrets store and governed through infrastructure as code.

5.2 Tenant isolation and segregation

Tenant isolation is a primary control objective for the IDR System. Customer data is isolated at both the application and the data layer, with every request evaluated against the authenticated user’s tenant context and permitted organisation hierarchy before data is returned. This is supported by least-privilege access roles, separation of environments, network segmentation and a web application firewall as infrastructure-level defence in depth.

Any data model that is not tenant-owned operational data is formally classified under a documented classification process, with a recorded business or security justification, and new classifications require documented review by the development team and the ISMS owner.

Network access to databases and private services is restricted to approved private network paths. Networks are segregated according to data classification, so that systems processing personal data are separated from those that do not. Alignment between the virtual network configuration and the underlying physical network model is verified through a monthly automated configuration drift check and periodic review of network access rules.

5.3 Cryptography and key management

• All customer data and security-sensitive operational data is encrypted at rest, using AES-256 symmetric encryption. Dedicated IDR-managed keys in the cloud key management service are used for data stores where key separation is required by the ISMS risk assessment.
• Object storage holding IDR System data uses server-side encryption, and storage policies require encrypted transport.
• Public web and API endpoints enforce HTTPS with a minimum of TLS 1.2, with TLS 1.3 preferred where client compatibility permits. HTTP-to-HTTPS redirection is enforced. Database and internal service traffic uses private or encrypted network paths; any exception requires documented risk acceptance.
• Key management follows industry standards including NIST SP 800-57. Managed key rotation is enabled, with a maximum key expiration of one year, and key revocation and recovery follow a documented schedule.
• Access to keys and secrets is tightly controlled under the IDR Oy Access Control Policy.
• Customer-supplied key material (BYOK) and external key stores are not offered. All encryption keys are managed by IDR Oy within the cloud key management service.

5.4 Logging, monitoring and customer visibility

ISO/IEC 27017 guidance on control 12.4.1, together with control CLD.12.4.5 (second edition clauses 8.15 and 8.16), requires the provider to give the customer logging capabilities and information, and the capability to monitor specified security aspects of the cloud service it uses. IDR Oy’s position is as follows.

IDR Oy operates automated alarms across database health, application and API health, capacity, errors, latency and availability. Security-relevant alerts are routed to on-call staff through a monitored escalation channel and responded to under the Incident Response Plan. Privileged operations and authorization denials within the application are logged.

5.5 Backup, recovery and resilience

ISO/IEC 27017 guidance on control 12.3.1 (second edition clause 8.13) requires the provider to give the customer the specification of its backup capability. IDR Oy’s specification is set out below.

Production services use a multi-availability-zone design, managed service capabilities, backup retention and tested recovery mechanisms. Data and backups are replicated across geographically separate availability zones so that services can fail over to a secondary site. Backups and replications are monitored for failure, and successive or pervasive failures are investigated and resolved.

5.6 Vulnerability, configuration and change management

• All cloud infrastructure changes are made through version-controlled infrastructure as code. Emergency changes follow an approved process and are reconciled back to code afterwards.
• A monthly automated drift check confirms that deployed infrastructure remains in sync with the approved configuration.
• Dependency vulnerabilities are managed through automated dependency update scanning across application and infrastructure package ecosystems.
• Dynamic application vulnerability scanning runs against deployed services on a scheduled basis; static analysis and linting run in the deployment pipeline, which fails the deployment when issues are found.
• Security configuration follows AWS security best practice for the services in use, and configuration compliance is monitored on an ongoing basis with findings tracked to the remediation timelines below. Compute hardening covers workload-level access scoping, dependency management, secure configuration, logging and monitoring.
• Cloud configuration findings, infrastructure-as-code findings, dependency vulnerabilities and runtime findings all follow the remediation timelines below.

Changes affecting information security in the production environment are tested, reviewed and approved before deployment, with documented managerial authorisation for changes of significant impact. Advance communication of changes, including schedules and a description of reasonably anticipated effects, is provided to relevant internal and external stakeholders. Emergency changes are documented and reviewed afterwards.

Vulnerabilities are assessed by IDR Oy and remediated within the following timeframes:

IDR Oy’s assessed severity may differ from the level generated automatically by scanning software or asserted by an external researcher, based on IDR Oy’s knowledge of the technical architecture and real-world exploitability. Vulnerability scans run on every code update, and threat intelligence sources relevant to the platform are monitored on a defined cycle.

5.7 Capacity management

Compute and storage are largely provisioned through managed and serverless scaling, so capacity headroom is primarily an AWS-provided assurance under the shared responsibility model. IDR Oy monitors utilisation and throttling signals through automated alarms and escalates sustained capacity constraints through the operational alert channel.

What this means for the customer: capacity is added automatically as demand rises. There is no provisioning request for the customer to raise, no capacity quota to negotiate, and no customer action required before a period of increased use. Customers do not need to forecast usage to IDR Oy in advance. Where a customer expects a step change in volume that would materially alter the shape of its use of the service, IDR Oy asks to be told through the agreed support channel so that limits and cost can be reviewed together, but this is not a precondition of the service scaling.

IDR Oy does not currently expose live resource-usage telemetry to customers. Customers requiring their own usage figures for capacity or cost planning can request them through the support channel.

5.8 Personnel

• All IDR Oy personnel with access to service data are bound by confidentiality obligations.
• Personnel are informed of relevant security procedures, their roles, and the consequences of breaching security rules, and receive security awareness training as part of onboarding and on an ongoing basis.
• Access to customer data follows least privilege on a documented need-to-know basis, with disciplinary action for unauthorised access.
• Background verification checks are carried out on IDR Oy personnel in accordance with Finnish employment and privacy legislation, proportionate to the role, the classification of the information to be accessed and the assessed risk. Finnish law permits criminal record extracts only for defined categories of work and does not allow them for general pre-employment screening, so criminal record checks do not form part of IDR Oy screening.
• Third parties with privileged or administrative access to IDR Oy production systems or networks are subject to a background check, or must provide evidence of an acceptable background, based on their level of access and the assessed risk.
• Personnel and third parties with access to company or customer information sign non-disclosure, confidentiality and code-of-conduct agreements, and formally acknowledge their security responsibilities at the time of hire or engagement.

6. Information security incident management

ISO/IEC 27017 guidance on control 16.1.1 (second edition clause 5.24) requires the provider to give the customer documentation covering the scope of incidents that will be reported, the level of disclosure, the target notification time, the notification procedure, contact details, and any available remedies. IDR Oy’s position is below.

Cloud incidents are managed under the IDR Oy Incident Response Plan, with evidence preserved from application, network, database, control-plane and security monitoring logs. Log retention for systems under investigation is extended for the duration of the investigation. All incidents are formally documented, and a documented root cause analysis is performed on verified critical incidents. The Incident Response Plan is reviewed and formally tested at least annually.

Incidents involving the underlying cloud infrastructure may be escalated to AWS Support through approved channels. IDR Oy remains responsible for customer communication, tenant impact assessment, evidence preservation and coordination of remediation within the IDR System.

7. Data deletion, exit and portability

ISO/IEC 27017 control CLD.8.1.5 (second edition clause 8.10) requires the provider to give information about the arrangements for removing customer assets on termination, to document those arrangements in the agreement, and to perform them in a timely manner, specifying which assets are removed and which are kept.

7.1 Deletion

• On deletion of customer data, environments or cloud assets, IDR Oy uses the native deletion mechanisms of the underlying cloud services together with approved application and operational procedures, covering object storage, databases and their snapshots, backups, storage volumes and stored secrets.
• Data already written to backups, snapshots, replicated storage, logs or archives expires under the approved retention and lifecycle periods rather than being physically overwritten on request.
• AWS is relied on for underlying media sanitisation, storage device lifecycle management and physical destruction.
• Deletion and decommissioning actions are evidenced through application logs, AWS activity records, ticket records, API responses or infrastructure change history.

7.2 Retention after termination

Active customer data is retained for as long as the customer remains an active customer, or until the customer requests deletion. After termination of the contract, customer data is retained in accordance with the contractual agreement between the customer and IDR Oy. In the absence of contractual retention terms, IDR Oy retains customer data for 180 days after contract termination, after which it is deleted. Deletion is carried out through an approved operational process that removes the customer’s data from the platform.

Disposal is suspended where IDR Oy is served with a subpoena or document request, or becomes aware of a governmental investigation, audit or litigation, until legal counsel determines otherwise.

• Written confirmation of deletion is provided to the customer on request.
• Data already written to backups expires with the recovery point that holds it. Because recovery points are held for 180 days, customer data deleted at the end of the 180-day post-termination period is fully removed from backups within a further 180 days. IDR Oy states this combined horizon explicitly rather than leaving it to be inferred.

7.3 Exit and portability

IDR Oy maintains the capability to give customers access to their data for exit and portability purposes. Device data can be exported through application functionality, and remaining customer data, including photographs and other stored content, is accessible through documented API endpoints or approved support processes.

Export is handled entirely by IDR Oy using its own tooling and documented API endpoints; no third-party or infrastructure-provider support process is involved, so exit requests are not dependent on an external party. The period during which export remains available after termination is set out in the contract signed with each customer.

8. Supply chain and cloud service partners

The following are the sub-processors with access to customer data. All are tracked and reviewed under the IDR Oy Third-Party Management Policy, including their data access scope and any cross-border processing implications. Sub-processors are engaged only under written agreements that impose information security and data protection terms no less onerous in all material respects than those IDR Oy owes its customers under the Data Processing Agreement, and IDR Oy remains liable for their acts and omissions. Each is assessed before engagement and reviewed at least annually, and IDR Oy gives customers written notice before adding or replacing a sub-processor, with a 30-day period in which the customer may object.

The IDR System is in some cases sold to end customers through resellers. Where a customer contracts with IDR Oy directly, IDR Oy acts as processor under a Data Processing Agreement with that customer. Where the service is resold, IDR Oy acts as sub-processor under a Data Processing Agreement with the reseller. The technical and organisational measures described in this statement apply to customer data in the IDR System in both cases.

9. Customer responsibilities

ISO/IEC 27017 asks the customer to review the responsibilities the provider allocates and confirm it can fulfil them. The following are the customer’s responsibilities in the IDR System.

• Use the service in accordance with the Agreement and acceptable use requirements.
• Manage its own users, requesting, approving and promptly revoking access as people join, move and leave.
• Ensure its users access only the data they are authorised to manage.
• Protect any credentials, exported data or content handled outside the IDR System.
• Maintain the accuracy and lawfulness of the data it submits, and ensure data subjects have been informed and lawful bases obtained, as set out in the DPA.
• Report suspected security incidents or misuse affecting its tenant through the agreed support channel, without undue delay.
• Determine whether the backup, retention, logging and recovery capabilities described in section 5 meet its own requirements, and implement additional measures where they do not.
• Request data export or deletion through the contractual and privacy processes described in section 7.
• Identify the laws and regulations governing its own use of the service and confirm they are consistent with the position described in section 3.

10. Contact and requesting further information

Requests for the ISO 27001 certificate, the evidence described in section 2.4, completed security questionnaires or clarification of anything in this statement should be addressed to:

Data Protection Officer, IDR Oy

dpo@idrcloud.com

IDR Oy, Erottajankatu 2, 00120 Helsinki, Finland

Annex A: ISO/IEC 27017 provider disclosure map

The controls below are those where ISO/IEC 27017 places a disclosure or provision obligation on the cloud service provider towards the cloud service customer. Identifiers are given for the first edition (ISO/IEC 27017:2015), which is the basis of the current assessment, with the second edition (ISO/IEC 27017:2026) clause alongside.