Security Documentation

DEEPXL AS

SECURITY DOCUMENTATION

Version 1.0 | Effective from 14 September 2026 Published in the legal section of our website at deepxl.ai — superseded versions remain available in the same place

This page is part of a contract. Schedule C to the DeepXL API Terms incorporates it by reference, and it completes Annex II to the Standard Contractual Clauses. Where this page is more specific than Schedule C it prevails; where it would provide less than Schedule C, Schedule C prevails. The version in force when a customer accepted the Terms, or when an Order Form took effect, is the version incorporated for that customer until a change is notified under clause 4.2 of Schedule 2.

It is written to be accurate rather than impressive. Section 11 sets out what DeepXL does not have and does not claim. A security page that overstates is worse than one that is modest, because everything on this one can be checked.

1. Scope

These measures apply to the DeepXL Services — the API, the Playground and the console — and to all Customer Content submitted to them, in both the Evaluation Period and production. Terms defined in the API Terms have the same meaning here.

DeepXL is a small company and says so plainly: it has no separate security team, and the measures below are designed to work without one. Where a control depends on a person rather than on automation, that is stated.

2. Where data is processed

• All Customer Content is processed and stored in Microsoft Azure, region East US 2 (Virginia, United States): compute, storage of submitted files, database, derived signals, the fraud-prevention layer, logs and backups.

• Storage and database redundancy is within the region only. Nothing is replicated to Azure’s paired region, and there is no geo-redundant backup.

• West US 3 (Arizona) is maintained as a disaster-recovery region. It holds no Customer Content in normal operation; Customer Content would be present there only during and after a declared failover.

• Azure OpenAI is used on Customer Content, on regional (Standard) deployments only. Global deployments, which could route inference outside the United States, are not used. Microsoft has approved DeepXL’s exemption from abuse monitoring, so prompts and responses are not retained by Microsoft for that purpose and there is no Microsoft human-review path. Microsoft commits contractually that the data is not used to train Microsoft or third-party models and is not shared with OpenAI.

• There is no regional or in-country processing option. Clause 8.3 of the API Terms states this and it cannot be varied by request.

The processing chain is published in full in the sub-processor list in the legal section of our website.

3. Encryption

4. Access control and personnel

• Role-based access on the principle of least privilege, with unique named accounts. Shared or generic accounts are not used for administrative access.

• Multi-factor authentication is enforced on every account with production access, without exception.

• Production access is held by two named individuals, which is the minimum number consistent with the service being operable if one is unavailable. All administration is performed from Norway.

• DeepXL Corp, which holds the Azure subscription, does not access Customer Content and cannot appoint anyone with access without DeepXL AS’s written consent.

• Access is reviewed periodically and revoked promptly on role change or departure. Because the number of people involved is two, review is a deliberate act rather than a report from a joiner-mover-leaver system.

• Customer-side access is the customer’s responsibility: credentials are issued to the customer entity, and the Administrator invites, designates and removes Authorised Users under clause 2.6 of the API Terms.

• Everyone with access to Customer Content is bound by written confidentiality undertakings that survive the end of their engagement.

• Security awareness training is provided and repeated periodically, and covers the specific risks of this service: handling identity documents, phishing directed at administrative credentials, and the limits on use of the Call reference in clause 13.6A of Schedule 2.

• Background screening is carried out before granting production access, to the extent lawful in the relevant jurisdiction.

5. Network and configuration

• Segmented architecture with development, test and production environments separated. Production data is not copied into development or test environments.

• Platform firewalling and hardened configurations; administrative interfaces are not exposed publicly.

• Dependencies are managed and updated, and security patches are applied on a timely basis. Platform-level patching of the infrastructure is Microsoft’s responsibility under the Azure shared-responsibility model.

• Malware protection on endpoints used for administration.

• Code review before changes reach production.

6. Logging and monitoring

• Security and access logging through Azure Monitor, Log Analytics and Application Insights, retained for 30 days, in the same region and the same subscription as the Services.

• Alerting on anomalous activity and on failure of the scheduled deletion processes described in section 7.

• Logs are protected against unauthorised alteration by the platform’s access controls.

• Every use of the Call reference in the fraud-prevention layer is logged, so that the limits in clause 13.6A of Schedule 2 are auditable and not merely promised.

• Where a processing operation fails, content from a submitted file may appear in an error log. Those logs are held in the same subscription and region and are deleted after 30 days. This is disclosed because it is the one place Customer Content exists outside the storage covered by section 7.

7. Retention and deletion

• A customer may request deletion of the whole account, or of a single file identified by its Call reference, at any time under clause 8.3 of the API Terms and clause 11 of Schedule 2.

• Deletion is enforced by automation, not by a manual routine, and both processes run in production today.

• Customer Content is not used to train, fine-tune, validate or evaluate any model (clause 4.6 of the API Terms). De- identification takes place before any use for product improvement, not afterwards.

8. Data minimisation as a security measure

The most effective protection DeepXL applies is not holding data it does not need. This is recorded here because it is the measure the transfer assessment relies on, and because it is verifiable against the contract rather than a matter of assertion:

• The fraud-prevention layer holds no file, copy, reproduction or image, and no content of any field. A compelled disclosure of the layer would yield fingerprints and signatures, not documents or identities. Clause 13.2A of Schedule 2 makes those limits contractual and states that they cannot be widened without amending the Terms.

• The layer holds no customer identifier, account identifier or API credential identifier — only a reference to the Call, whose use is confined by clause 13.6A.

• No special categories, criminal-offence data, genetic data or biometric data are held, extracted, derived, indexed or matched on as such, and no biometric template is generated. Biometric processing is outside the scope of the Services entirely under clause 2.2.

• Submitted files exist for twelve months and are then unrecoverable, which limits the window in which any document exists to be compelled or breached.

• Registration collects four items only, and no payment card data is held at any point.

• Quality-assurance review is carried out on the minimum sample necessary, by authorised personnel only, and solely to verify that Outputs returned to the customer are correct and to detect and correct systematic error. It is not a general right to read Customer Content, and clause 2.2(c) of Schedule 2 limits it to that purpose.

9. Sub-processors

• Due diligence before engagement, including verification of Data Privacy Framework certification where DeepXL relies on it.

• Contractual flow-down under clause 5.3 of Schedule 2, and the transfer mechanisms recorded in clause 9.3.

• Periodic review, and confirmation at least annually that a certification relied on remains in force.

• Notice of an intended addition or replacement, with a right to object and terminate, under clause 5.2 of Schedule 2. The current list is published in the legal section of our website.

• No third-party document parsing, no model API outside Azure, no external tracing or observability, and no third-party error logging touches Customer Content, and no consultant or developer outside DeepXL AS holds production access. Customer Content does not appear in e-mail, chat, support tooling or any CRM.

10. Incident response

• A documented incident response plan with defined roles, containment steps, assessment of the risk to individuals, and the notification process in clause 10 of Schedule 2.

• DeepXL notifies the customer of a personal data breach affecting Customer Content without undue delay and provides the information the customer needs to meet its own obligations under Articles 33 and 34 of the GDPR. The seventy-two-hour period in Article 33(1) is the customer’s obligation as controller, not a DeepXL service level; clause 10 of Schedule 2 governs what DeepXL owes and when.

• DeepXL Corp is contractually obliged to notify DeepXL AS within twenty-four hours of becoming aware of a breach affecting Customer Content, which is shorter than DeepXL AS’s own obligation because it cannot meet that obligation unless it is told first.

• Where a public authority requests Customer Content, DeepXL notifies the customer unless prohibited by law, challenges the request where there are reasonable grounds to consider it unlawful, and does not disclose without informing the customer first unless prohibited.

11. What DeepXL does not have, and does not claim

Stated openly so that a security review does not have to discover it.

No security certification. DeepXL holds no ISO 27001 certification and no SOC 2 report, and will not imply otherwise. Clause 8.1 of Schedule 2 discloses this in the contract itself. If a certification is obtained, this page and that clause will be updated.

No third-party penetration test has been carried out. Security rests on the measures in this document, on the platform controls Microsoft provides, and on the small size of the attack surface described in section 9 — not on an external assessment.

No customer-managed encryption keys. See section 3.

No availability commitment during the Evaluation Period. Clause 2.7 of the API Terms applies. In production, P4.2 of Schedule 4 gives a commercially reasonable 99.5% target with no service credits.

No EEA or in-country processing option. See section 2.

12. Reporting a vulnerability

Report a suspected vulnerability to security@deepxl.ai. DeepXL will acknowledge receipt, investigate, and keep the reporter informed of the outcome. DeepXL will not pursue a good-faith reporter who tests only against their own account, does not access or alter another customer’s data, does not degrade the Services, and gives DeepXL a reasonable opportunity to remediate before publishing. Clause 3.3 of the API Terms otherwise prohibits probing and benchmarking, and this paragraph does not authorise it.

13. Customer and audit rights

• A customer may request the compliance information and standard record extracts described in clause 7.4 of Schedule 2 at no charge.

• Audit rights are in clause 8.2 of Schedule 2: remote-first, once per twelve months, no competitor auditor, and no access to another customer’s data, to source code, to model weights or to training data.

• Completed security questionnaires, bespoke reviews and bespoke evidence are chargeable under clause 7.4, at a rate notified in advance with an estimate and written approval. This page exists partly so that most questionnaires can be answered by pointing to it.

14. Changes and version history

This page carries a version number and an effective date. Every version, current and superseded, remains retrievable in the legal section of our website, because Schedule C incorporates the version in force at the time of acceptance and that version must remain provable. A change that reduces the measures below what Schedule C requires cannot take effect by publishing this page; it would require an amendment to the Terms under clause 14.1.