Aspose Digital Operational Resilience Act (DORA) Statement

Last updated: 19 December 2024

Introduction

Aspose Pty Ltd (“Aspose”) is a leading software provider offering award-winning APIs for file format manipulation, including creation, conversion, and editing capabilities. Aspose serves customers globally by delivering self-hosted APIs that operate independently within customer-managed environments.

As a third-party ICT service provider, Aspose plays a supportive role in helping customers meet their own digital operational resilience obligations under the Digital Operational Resilience Act (DORA). Aspose’s software solutions are designed with robust security and resilience measures to ensure reliable performance while enabling customers to maintain full control over their deployment, security, and ICT risk management.

This document outlines Aspose’s alignment with applicable DORA requirements and highlights Aspose’s policies, processes, and practices that contribute to customers’ ICT risk management, operational resilience, and compliance goals.

1. Purpose

The purpose of this document is to:

  1. Clearly demonstrate Aspose’s approach to aligning with the relevant requirements of the Digital Operational Resilience Act (DORA) as a third-party ICT service provider.
  2. Provide transparency regarding Aspose’s policies, procedures, and frameworks that support ICT risk management, software security, and operational resilience.
  3. Highlight Aspose’s role and responsibilities, emphasizing that its APIs are self-hosted and operate independently of Aspose’s website infrastructure.

This document serves as a resource for customers conducting due diligence to evaluate Aspose’s ability to support their compliance with DORA requirements.

2. Scope

This document covers Aspose’s alignment with DORA requirements relevant to its role as a third-party ICT service provider. Specifically:

  • Aspose’s internal policies and processes that address ICT risk management, software development security, and third-party risk management.
  • Aspose’s contribution to digital operational resilience through its secure and reliable self-hosted APIs.
  • Clarification of the boundary of Aspose’s responsibility: While Aspose provides secure software solutions, customers are responsible for managing the deployment, ICT risk, and operational resilience of Aspose’s APIs within their environments.
  1. Aspose’s APIs are self-hosted and do not rely on Aspose’s infrastructure for operation, which ensures independence and resilience.
  2. All referenced policies are available at Aspose’s trust and security portal: https://trust.aspose.com.

3. Aspose’s Alignment With DORA Key Areas

3.1. Form of Contract

Article 30(1)

Requirement: The rights and obligations of the financial entity and of the ICT third-party service provider shall be clearly allocated and set out in writing.

The full contract shall include the service level agreements and be documented in one written document available to the parties on paper, or in a document with another downloadable, durable and accessible format.

Aspose Policy: Aspose provides its customers with a clear and detailed End-User License Agreement (EULA), which outlines the rights and obligations of both parties.

The EULA governs the use of Aspose’s self-hosted APIs and is available in a durable and accessible format.

Aspose does not provide SLAs, as customers fully manage and operate Aspose APIs in their own infrastructure.

Supporting Evidence:

3.2. Services and service levels

Article 30(2)(a)

Requirement: The contractual arrangements on the use of ICT services shall include a clear and complete description of all functions and ICT services to be provided by the ICT third-party service provider.

Aspose Policy: Aspose provides a clear and complete description of all functions and services of its APIs through:

  • Product documentation detailing the capabilities, supported platforms, and usage of Aspose APIs.
  • The End-User License Agreement (EULA), which governs the terms of software use.
  • Release notes and feature updates, ensuring transparency on functionality changes. Aspose’s APIs are self-hosted, and customers manage their deployment and ICT environments.

Supporting Evidence:

Article 30(2)(e)

Requirement: The contractual arrangements on the use of ICT services shall include service level descriptions, including updates and revisions thereof.

Aspose Policy: Aspose provides detailed descriptions of its API services, including their functions, features, and usage.

Updates and revisions are communicated through product release notes and technical documentation.

Aspose does not offer service level agreements (SLAs) as its APIs are self-hosted and fully managed within the customer’s environment.

Supporting Evidence:

Article 30(3)(a)

Requirement: The contractual arrangements on the use of ICT services supporting critical or important functions shall include full service level descriptions, including updates and revisions thereof with precise quantitative and qualitative performance targets within the agreed service levels to allow an effective monitoring by the financial entity of ICT services and enable appropriate corrective actions to be taken, without undue delay, when agreed service levels are not met.

Aspose Policy: Aspose provides detailed product documentation and descriptions of its APIs, including functional capabilities, usage guidance, and updates through release notes.

However, Aspose does not offer service level agreements (SLAs) or quantitative performance targets, as its APIs are self-hosted and operated entirely within the customer’s infrastructure.

Customers retain full responsibility for monitoring performance, ensuring resilience, and taking corrective actions as needed.

Supporting Evidence:

Article 30(3)(b)

Requirement: The contractual arrangements for the provision of critical or important functions shall include notice periods and reporting obligations of the ICT third-party service provider to the financial entity, including notification of any development that might have a material impact on the ICT third-party service provider’s ability to effectively provide the ICT services supporting critical or important functions in line with agreed service levels.

Aspose Policy: Aspose provides regular release notes and notifications to customers, detailing any updates, changes, or revisions to its APIs that could impact functionality.

As Aspose’s APIs are self-hosted and managed within customer infrastructure, Aspose’s responsibility is limited to providing updates and ensuring software integrity.

Customers maintain full operational control and must assess the impact of changes on their critical functions.

Supporting Evidence:

3.3. Termination

Article 28(7)

Requirement: Financial entities shall ensure that contractual arrangements on the use of ICT services may be terminated in any of the following circumstances:

  • significant breaches by the ICT third-party service provider of applicable laws, regulations, or contractual terms;
  • circumstances identified throughout the monitoring of ICT third-party risk that are deemed capable of altering the performance of the functions provided through the contractual arrangement, including material changes that affect the arrangement or the situation of the ICT third-party service provider;
  • ICT third-party service provider’s evidenced weaknesses pertaining to overall ICT risk management and the way it ensures the availability, authenticity, integrity, and confidentiality of data;
  • where the competent authority can no longer effectively supervise the financial entity as a result of the conditions of, or circumstances related to, the respective contractual arrangement.

Aspose Policy: Aspose’s End-User License Agreement (EULA) provides clear terms under which the use of Aspose’s APIs can be terminated.

These include:

  • Breaches of licensing terms by either party.
  • Conditions where software misuse, material changes, or other violations impact compliance with the agreement.

Aspose’s APIs are self-hosted, and customers retain full control over deployment and risk monitoring.

Aspose ensures the software’s availability, integrity, and security through its Secure Software Development Lifecycle (SDLC) and vulnerability management practices.

Supporting Evidence:

Article 30(2)(h)

Requirement: The contractual arrangements on the use of ICT services shall include termination rights and related minimum notice periods for the termination of the contractual arrangements, in accordance with the expectations of competent authorities and resolution authorities.

Aspose Policy: Aspose’s End-User License Agreement (EULA) includes clear terms outlining the rights for termination of the agreement and related notice periods.

Termination may occur for breaches of licensing terms or misuse of Aspose’s software.

Given that Aspose’s APIs are self-hosted, customers maintain full operational control and can stop using the software at their discretion.

Aspose does not impose additional constraints beyond those outlined in the EULA.

Supporting Evidence:

Article 30(3)(f)

Requirement: The contractual arrangements for the provision of critical or important functions shall include exit strategies, in particular the establishment of a mandatory adequate transition period:

  • during which the ICT third-party service provider will continue providing the respective functions or ICT services with a view to reducing the risk of disruption at the financial entity or to ensure its effective resolution and restructuring;
  • allowing the financial entity to migrate to another ICT third-party service provider or change to in-house solutions consistent with the complexity of the service provided.

Aspose Policy: Aspose’s End-User License Agreement (EULA) allows customers to continue using Aspose’s self-hosted APIs during the license term, enabling a smooth transition without reliance on Aspose’s infrastructure.

Since Aspose’s APIs are self-hosted, customers retain full control over migration processes, whether transitioning to another ICT service provider or implementing in-house solutions.

Aspose ensures ongoing software availability during the transition period through licensing terms, provided customers adhere to the agreement.

Supporting Evidence:

3.4. Subcontracting

Article 30(2)(a)

Requirement: The contractual arrangements on the use of ICT services shall indicate whether subcontracting of an ICT service supporting a critical or important function, or material parts thereof, is permitted and, if so, the conditions applying to such subcontracting.

Aspose Policy: Aspose’s End-User License Agreement (EULA) does not involve subcontracting of services, as Aspose’s APIs are delivered as self-hosted solutions.

Customers deploy and operate Aspose’s software independently within their own infrastructure, ensuring no reliance on subcontractors for delivery or operation.

Aspose maintains control over the development, testing, and release of its APIs without external subcontracting.

Supporting Evidence:

3.5. Audit, access and information

Article 30(3)(e)

Requirement: The contractual arrangements for the provision of critical or important functions shall include the right to monitor on an ongoing basis the ICT third-party service provider’s performance, which entails the following:

  • unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority, and the right to take copies of relevant documentation on-site if they are critical to the operations of the ICT third-party service provider, the effective exercise of which is not impeded or limited by other contractual arrangements or implementation policies;
  • the right to agree alternative assurance levels if other clients’ rights are affected;
  • the obligation of the ICT third-party service provider to fully cooperate during the onsite inspections performed by the competent authorities, the lead overseer, financial entity or an appointed third party;
  • the obligation to provide details on the scope and procedures to be followed and frequency of such inspections and audits.

Aspose Policy: Aspose’s End-User License Agreement (EULA) governs the terms under which Aspose’s APIs are provided.

As Aspose’s APIs are self-hosted, customers operate the software independently within their own infrastructure. Aspose does not manage or monitor customer environments, eliminating the need for onsite inspections or access rights to operational performance.

Customers are responsible for monitoring and auditing the performance of the APIs within their ICT environments.

Aspose ensures software security, integrity, and updates through its internal development processes.

Supporting Evidence:

3.6. Location

Article 30(2)(b)

Requirement: The contractual arrangements on the use of ICT services shall include the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity if it envisages changing such locations.

Aspose Policy: Aspose’s APIs are self-hosted, and customers manage deployment and operation within their own environments, including control over data storage and processing locations.

Aspose does not process or store data as part of the service provided by its APIs.

However, customer data (e.g., name, address, title) used for purchasing the software is stored by Aspose for administrative and licensing purposes.

This data is processed in compliance with applicable regulations and handled securely.

Any changes to data storage locations would be communicated as part of Aspose’s privacy and licensing policies.

Supporting Evidence:

3.7. Data and security

Article 30(2)(c)

Requirement: The contractual arrangements on the use of ICT services shall include provisions on availability, authenticity, integrity, and confidentiality in relation to the protection of data, including personal data.

Aspose Policy: Aspose ensures the availability, authenticity, integrity, and confidentiality of its software products through secure development and testing practices, as outlined in its Secure Software Development Lifecycle (SDLC).

Aspose’s APIs are self-hosted, meaning customers retain full control over data protection within their environments.

Aspose does not process or store data as part of the API service.

Aspose stores customer data (e.g., name, address, title) for licensing and administrative purposes. Such data is handled securely and in compliance with applicable regulations, including GDPR, as outlined in the Aspose Data Processing Agreement (DPA).

The DPA defines Aspose’s obligations for protecting personal data and ensuring its confidentiality, integrity, and security.

Supporting Evidence:

Article 30(2)(d)

Requirement: The contractual arrangements on the use of ICT services shall include provisions on ensuring access, recovery and return in an easily accessible format of personal and non-personal data processed by the financial entity in the case of insolvency, resolution or discontinuation of the business operations of the ICT third-party service provider, or in the case of termination of the contractual arrangements.

Aspose Policy: Aspose’s APIs are self-hosted, meaning all personal and non-personal data processed through the APIs is fully controlled and managed by customers within their own environments.

In the event of termination, insolvency, or discontinuation of Aspose’s operations, there is no reliance on Aspose for data recovery or access, as Aspose does not store or process such data as part of the service.

Customer licensing and administrative data (e.g., name, address, title) is securely stored by Aspose for operational purposes. Aspose’s Data Processing Agreement (DPA) ensures compliance with applicable regulations regarding data recovery, access, and return.

Supporting Evidence:

Article 30(3)(d)

Requirement: The contractual arrangements for the provision of critical or important functions shall include the obligation of the ICT third-party service provider to participate and fully cooperate in the financial entity’s threat-led penetration testing.

Aspose Policy: Aspose’s APIs are self-hosted, meaning customers deploy and operate the software within their own environments.

As such, Aspose does not participate in customer threat-led penetration testing (TLPT) since it does not manage or have access to customer infrastructure.

Aspose ensures the security of its APIs through its own rigorous Secure Software Development Lifecycle (SDLC), including internal penetration testing, vulnerability assessments, and secure coding practices.

Customers remain responsible for conducting testing within their environments to ensure operational resilience.

Supporting Evidence:

3.8. Business continuity and operational resilience

Article 30(3)(c)

Requirement: The contractual arrangements for the provision of critical or important functions shall include requirements for the ICT third-party service provider to implement and test business contingency plans and to have in place ICT security measures, tools, and policies that provide an appropriate level of security for the provision of services by the financial entity in line with its regulatory framework.

Aspose Policy: Aspose has implemented robust internal business contingency plans and ICT security measures to ensure the security and resilience of its software products. These measures include:

  • Business continuity strategies documented in the Business Continuity Policy.
  • Secure software development practices outlined in the Secure Software Development Lifecycle (SDLC).
  • Proactive risk mitigation through the Vulnerability Management Policy. Aspose’s APIs are self-hosted, meaning customers are responsible for implementing and testing their own contingency plans and security measures within their environments. Aspose ensures its software provides a secure foundation for customers’ operational resilience.

Supporting Evidence:

Article 30(2)(f)

Requirement: The contractual arrangements on the use of ICT services shall include the obligation of the ICT third-party service provider to provide assistance to the financial entity at no additional cost, or at a cost that is determined ex-ante, when an ICT incident that is related to the ICT service provided to the financial entity occurs.

Aspose Policy: Aspose provides assistance to customers through its support channels for incidents related to the functionality or security of its APIs. This support is governed by Aspose’s End-User License Agreement (EULA), where the terms for assistance are clearly outlined.

As Aspose’s APIs are self-hosted, incidents occurring within customer environments (e.g., deployment, operations) are outside Aspose’s scope of responsibility.

Aspose ensures prompt communication of fixes, patches, and updates for software-related issues, at no additional cost.

Supporting Evidence:

Article 30(2)(i)

Requirement: The contractual arrangements on the use of ICT services shall include the conditions for the participation of ICT third-party service providers in the financial entities’ ICT security awareness programs and digital operational resilience trainings.

Aspose Policy: Aspose does not participate in customer-led ICT security awareness programs or digital operational resilience trainings, as Aspose’s APIs are self-hosted and fully managed within customer environments.

Aspose ensures its own staff are trained on ICT security and resilience through its Information Security Policy, which includes regular security awareness programs, training sessions, and resilience testing practices as part of Aspose’s internal operations.

Supporting Evidence:

4. Conclusion

Aspose is committed to supporting customers’ compliance efforts with the Digital Operational Resilience Act (DORA) through its secure, reliable, and self-hosted APIs. Our documented policies, such as the Secure Software Development Lifecycle (SDLC), Vulnerability Management Policy, and Business Continuity Policy, reflect our focus on delivering resilient software products.

While this document outlines Aspose’s alignment with DORA requirements, we understand that customer needs may vary. Aspose remains open to feedback and will continue to refine its policies and practices as necessary to address specific customer requirements and evolving regulatory expectations.

Aspose is committed to complying with all applicable legal, regulatory, and industry requirements related to this statement. Where specific regulations or standards apply, Aspose will ensure alignment to protect customer data, meet business obligations, and maintain operational integrity.

5.1. Compliance Principles

  • Adherence: Aspose follows all relevant legal and regulatory requirements applicable to its operations and systems.
  • Alignment with Standards: While Aspose may not hold formal certifications, it aligns its practices with recognized industry frameworks and best practices to ensure compliance.

5.2. Ongoing Compliance Monitoring

Aspose regularly reviews its internal processes, policies, and product offerings to ensure ongoing compliance with relevant laws and industry standards.

Compliance audits and reviews are conducted periodically to ensure the effectiveness of security and privacy controls.

6. Periodic Review and Statement Updates

Periodic Review: This DORA Statement will be reviewed periodically or as required to address emerging threats, regulatory changes, or Aspose’s evolving operational needs. This ensures the statement remains aligned with current access control best practices and business requirements.

Statement Updates: Updates to the statement will be communicated to all employees, contractors, and relevant stakeholders. Any significant changes will be accompanied by training or guidance to ensure continued adherence to access control principles.

7. Approval

This Access Control Policy was approved by the Board of Directors of Aspose Pty Ltd on 2024.12.01.