Technical Specification of the Anjana Data Platform SaaS Service

1 Purpose and scope

This document describes the technical specification of the Anjana Data Platform SaaS service, including:

• This document describes the technical specification of the Anjana Data Platform SaaS service offered by Anjana Data SL, including:

• Infrastructure profiles (PRE, Base, Standard, Balanced) and their capabilities.

• SaaS packages offered and included environments (PRO/PRE).

• Security controls included by default (baseline) and isolation principles.

• Additional connectivity/security options.

• Backups, retention and recovery objectives (RPO/RTO).

• Usual operating regions.

• Provider and customer responsibilities.

The purpose of this document is to provide the customer with transparency and confidence regarding the architecture and security of the service, without exposing details that could compromise the security posture of Anjana Data SL.

2 Definitions

• Instance: a complete and independent deployment of Anjana Data Platform (components, configuration, endpoints and associated resources).

• Environment: operational classification (PRO, PRE, POC, DEV, TEST). In SaaS, each environment is typically implemented as an independent instance.

• PRO: production environment (infrastructure sized for production).

• PRE: non-production environment (validation/pre-production).

3 SaaS service reference architecture

3.1 Main components (high level)

Anjana Data Platform SaaS is deployed on cloud infrastructure using a “layered” segmentation model:

• Controlled entry layer: UI/API access is centralized through a managed entry point (load balancer where applicable) protected by security controls (WAF and DDoS mitigation).

• Application layer on private network: platform components operate in private subnets, not directly exposed to the Internet.

• Managed data layer: object storage (S3) and database (managed DB) sized according to the infrastructure profile.

• Operations layer: periodic backups and recovery mechanisms with defined RPO/RTO objectives (section 9).

4 SaaS packages and included environments

4.1 Offered packages and mapping to infrastructure profiles

SaaS packages consist of one or two instances (environments), each deployed with an infrastructure profile:

5 Infrastructure profiles (PRE / Base / Standard / Balanced)

5.1 Capabilities per profile

Infrastructure profiles define technical sizing and high-availability capabilities, as well as backup/retention parameters.

5.2 Sizing principles

• PRE: environment oriented toward validation and pre-production.

• Base: robust non-production environment or low-load production environment, depending on package design.

• Standard: production environment with separation of responsibilities (nodes) and sizing for higher loads.

• Balanced: production environment with increased capacity and redundancy (replication/LB as per table).

6 Security included by default (baseline)

All SaaS deployments incorporate a set of baseline security controls aimed at protecting availability, reducing exposure surface and strengthening access control.

6.1 Protection against attacks and traffic control

• DDoS Mitigation (AWS Shield Standard): automatic protection for network and application layer attacks, aimed at preserving availability.

• Web application filtering and protection (AWS WAF): rules to mitigate common attacks (e.g., injection and scripting) and bot control, applied to HTTP/HTTPS traffic.

• Domain management (Route 53): management of service DNS routing.

Objective: ensure that incoming traffic passes through an inspection and mitigation layer before reaching the application.

6.2 Network isolation and minimal exposure

• Private subnets: platform components are deployed in a private network, with no direct exposure to the Internet.

• Security Groups / traffic control: strict control of inbound/outbound traffic, enabling only what is necessary for the service.

• Centralized entry: external access is concentrated at a controlled entry point (load balancer where applicable), where the above controls are applied.

Objective: reduce attack surface and avoid unnecessary exposure of internal components.

6.3 Access control and identity integrations

• Zeus (authentication and authorization): authentication/authorization layer compatible with multiple identity providers (e.g., LDAP, AD, cloud providers and others).

Objective: provide robust and flexible access control, aligned with the customer’s corporate integrations (according to the package contracted in the Licensing Model).

6.4 Web server whitelisting (where applicable)

• Web server with whitelist: ability to restrict access by authorized domains/IPs (configurable according to customer needs and their connectivity package).

Objective: reinforce the principle of “allow only what is necessary”.

7 Additional connectivity and security (optional packages)

7.1 NO AWS / ON-PREMISE — VPN Site-to-Site

• Oriented toward customers without AWS or with on-premise/multicloud architecture.

• Secure VPN-type connectivity between networks.

7.2 STANDARD — AWS Transit Gateway

• Oriented toward hybrid or multi-network architectures with centralized integration.

• Facilitates bidirectional private connectivity in AWS/hybrid environments.

7.3 PREMIUM A — AWS PrivateLink (Zero Trust approach for plugin connectivity)

• Option oriented toward mixed scenarios, where PrivateLink connectivity is used for specific needs (for example, connectivity with plugins or integrations), maintaining where applicable the UI/API access in accordance with the service baseline (WAF/Shield/whitelist and associated controls).

• Facilitates a “Zero Trust” model at service level for specific components without requiring full isolation of the front end.

7.4 PREMIUM B — AWS PrivateLink (UI/API + plugins, no Internet egress)

• In PREMIUM B, access to the service UI/API is performed exclusively via AWS PrivateLink, and the architecture is designed so that the SaaS instance has no Internet egress (UI/API is not exposed to the public Internet). This option provides the highest level of access isolation, concentrating communication on private connectivity at the service level.

Comparative summary of the different additional security packages

8 Usual operating regions

The SaaS service is offered as standard in the following usual operating regions:

• Europe (Frankfurt) — eu-central-1

• Europe (Spain) — eu-south-2

• US East (N. Virginia) — us-east-1

• US West (N. California) — us-west-1

• Europe (Ireland) — eu-west-1 (only WP)

When the customer requests a different region, a “non-standard region” add-on may apply in accordance with the Licensing Model. In the event that the region becomes considered standard due to additional adoption, the cost computation cessation policy defined in that model shall apply.

9 Backups, retention and recovery (RPO/RTO)

9.1 Backups and retention

Service backups are performed with the frequency and retention defined by the infrastructure profile (see table 5.1-A).

9.2 Recovery objectives

• RPO (Recovery Point Objective): 24 hours.

• RTO (Recovery Time Objective): 24 hours.

The above objectives apply to the standard service. Higher requirements (lower RPO/RTO, extended retention or specific obligations) are treated as a particular condition and/or add-on, subject to technical evaluation.

10 Service operations (high level)

Anjana Data SL provides SaaS service operations in accordance with the scope defined in the Licensing Model (Managed Service), including:

• Service operation and maintenance.

• Planned updates.

• Operational monitoring.

11 Customer responsibilities (SaaS)

The customer is responsible for:

• Managing service use in accordance with their licensing (governed objects, integrations, plugins, etc.).

• Maintaining an administrative contact for operational notifications.

• When contracting additional connectivity/security: fulfilling technical prerequisites under their control (e.g., configuration in their network/VPC or equivalent components).

• Providing the information necessary for configuration (domains, certificates if applicable, identity systems) according to the contracted scope.