Information Classification Policy

This Policy establishes OORT Labs' single information classification scheme: how each information asset is categorised by sensitivity and which minimum protection controls apply to each category throughout its entire lifecycle — creation, storage, use, transmission, sharing, retention and disposal.

The goal is to ensure that protection is proportional to the impact of unauthorised disclosure, alteration or unavailability, avoiding both the under-protection of critical data and the unnecessary cost of over-protecting public information.

The scope covers:

• Customer Data transmitted, processed and stored on the OORT Flows Platform (flow content, documents, prompts, outputs, attachments and execution metadata);
• Platform operational data (logs, telemetry, configuration, integration credentials);
• OORT Labs corporate information (source code, technical documentation, contracts, employee data);
• Information held by sub-processors and integrated AI model providers;
• Any medium — digital, printed or verbal — in which the information is materialised.

This Policy is binding on all employees, interns, service providers and third parties with access to information assets of OORT Labs or its Customers.

When the applicable level is unclear, the most restrictive classification among the candidates prevails until the Information Owner formally decides.

OORT Labs adopts four levels of classification, from least to most sensitive. Every information asset receives exactly one level.

In the absence of an explicit classification, all Customer Data is treated by default as Confidential, and all special categories of personal data as Restricted.

Classification is determined by the greatest potential impact across the three classic dimensions of information security, plus legal and regulatory impact:

• Confidentiality — what is the harm if the information is disclosed to someone who should not access it?
• Integrity — what is the harm if the information is altered in an unauthorised or undetectable way?
• Availability — what is the harm if the information becomes unavailable beyond the defined RTO/RPO?
• Legal and regulatory impact — would disclosure breach LGPD, GDPR, contractual confidentiality or sector-specific rules (banking, securities, health, legal professions)?
• Impact on data subjects — is there a risk of discrimination, fraud, or physical, moral or financial harm to natural persons?

The aggregation rule applies: a set of individually Internal data may be classified as Confidential or Restricted when the combination enables sensitive inference or the re-identification of data subjects.

Classification is reviewed whenever there is a material change of context — a new contract, a new data type in the flow, a regulatory change — and at least annually.

Every asset classified as Internal, Confidential or Restricted must be labelled visibly and persistently. Public information requires no label.

• Documents and presentations: label in the footer of every page (e.g. CONFIDENTIAL — OORT Labs);
• Email: label on the first line of the body for Confidential or Restricted subjects;
• Repositories and systems: classification metadata at repository, bucket, table or collection level;
• Flows and agents in OORT Flows: a per-flow classification attribute that conditions the controls applied at runtime;
• Physical media and printouts: marking on the header and on the transport envelope;
• Verbal communication: the level must be stated at the start of the conversation when Confidential or Restricted.

The label follows the information through copies, extracts and derivatives. An extract from a Restricted document remains Restricted, unless formally declassified by the Information Owner.

The table below sets the floor of applicable controls. Stricter controls may be required by contract, by sector-specific rules or by the flow's risk assessment.

Information classification complements, and does not replace, the personal data protection regime. The mapping adopted is:

Data classified as Restricted requires a documented specific legal basis, a necessity and proportionality assessment and, where applicable, a Data Protection Impact Assessment (DPIA).

OORT Flows integrates AI model providers. Information classification defines what may be sent to each provider and under which conditions:

• Content flowing through the platform is not used to train OORT Labs models, nor made available to third parties for that purpose;
• Integrated providers are only approved subject to a contractual zero data retention clause or limited, auditable retention;
• Restricted information is only sent to models after sensitive-data filtering (PII, PHI, secrets) or with explicit approval recorded in the flow;
• Credentials, keys and secrets are never part of prompts, context or attachments sent to models;
• AI-generated outputs inherit the highest classification among the inputs used to generate them;
• Execution logs containing Confidential or Restricted content follow the same access and retention controls as the source data;
• Provider choice and processing region may be restricted by classification level and by the Customer's data residency requirements.

The algorithmic risk, human oversight and transparency controls associated with these flows are described in the Responsible AI and Compliance Commitment.

Information is retained only for as long as necessary to fulfil its purpose, legal and regulatory obligations and the contract signed with the Customer.

• Retention: periods per data type are set out in the Privacy Policy and the applicable contract; once the period ends, deletion is automatic or approved by the Information Owner;
• Declassification: lowering a level requires formal approval from the Information Owner, recording the date, reason and responsible person — sensitive information that has lost criticality over time may be downgraded;
• Digital media disposal: secure deletion, overwriting or cryptographic destruction of keys, according to level;
• Physical media disposal: cross-cut shredding or incineration, with a certificate when Restricted;
• Return to the Customer: on contract termination, data is exported in the agreed format and deleted from production and backup environments within the contracted timeframes;
• Legal hold: suspends disposal for as long as the preservation obligation lasts, with the scope and justification recorded.

Sharing Confidential or Restricted information with third parties requires all of the following:

1. A demonstrated need and specific purpose, limited to the minimum data necessary;
2. An active contract with confidentiality clauses (NDA) and, where personal data is involved, a Data Processing Agreement (DPA);
3. A security assessment of the third party proportional to the classification level, with periodic reassessment;
4. An adequate international transfer mechanism (Standard Contractual Clauses, adequacy decision or equivalent safeguard) where there is a cross-border transfer;
5. A record of the sharing — what, to whom, when, for how long and on which legal basis;
6. Maintenance of the classification level by the third party, with an obligation to return or destroy the data at the end of the relationship.

An up-to-date list of sub-processors is available to the Customer on request, as provided in the Privacy Policy.

The following constitute breaches of this Policy, among others: assigning a lower classification than warranted, removing labels without authorisation, sharing information above the level permitted to the recipient, storing Confidential or Restricted data in a non-approved service, and disposing of information without following the applicable procedure.

• Any suspicion must be reported immediately to the security channel, without attempting an independent fix;
• The incident is triaged, contained and classified by severity and impact on data subjects within 24 hours of becoming known;
• Incidents involving personal data follow the response plan, with notification to the ANPD and to data subjects where there is relevant risk, and to the competent European authority within 72 hours where GDPR applies;
• Affected Customers are notified according to the contracted SLA, with a description of the scope, the measures taken and recommendations;
• Deliberate breaches subject the responsible party to disciplinary and, where applicable, contractual and legal measures.

• Mandatory information classification training during onboarding of new staff and annual refreshers, with completion records;
• Periodic internal audits of compliance, including labelling sampling, access permission reviews and disposal testing;
• Independent audit and certifications maintained under the security programme described in the Responsible AI and Compliance Commitment;
• Exceptions to this Policy are only valid if formalised, with a fixed term, business justification, compensating control and approval from Information Security and the DPO;
• Review of this Policy at least annually or upon a relevant regulatory, technological or organisational change.

This Policy is grounded in the controls of ISO/IEC 27001/27002 (A.5.12 classification of information, A.5.13 labelling of information, A.5.14 information transfer), ISO/IEC 27701 and the NIST Cybersecurity Framework.

Questions about the classification of a specific asset, exception requests and incident reports should be directed to the channels below:

• Information Security and incidents: [security@oortlabs.com]
• Data Protection Officer (DPO): [dpo@oortlabs.com]
• General privacy: [privacy@oortlabs.com]
• AI governance: [ai-governance@oortlabs.com]

Material changes to this Policy are communicated to the Customer with reasonable notice and reflected in the version information above.