Technical and Organisational Measures

This document describes the evidenced application baseline and forms standard Schedule B of the DPA automatically through acceptance of the applicable Terms. No separate institutional signature is required for that baseline. It is not a certification, independent audit report or claim that every enterprise control is supplied. Additional controls can be agreed in an optional enterprise schedule where the intended use requires them.

Customer Data is stored and processed within the EU. Data Residency & Processing Locations defines the boundary; the site does not publish detailed infrastructure locations. The level of measures must be appropriate to the intended data and risks, not inferred solely from this location commitment.

The application verifies identity on the server, checks organisation membership and applies role and record-access checks. Personal and organisation content is scoped to the relevant user, workspace, matter or project. Restricted operations require the relevant role. Session handling uses server-side cookie protections; this is not a claim that SSO, SAML, SCIM or organisation-wide MFA is included in every plan.

Administrators must grant least-privilege access, review shared records and remove memberships when access is no longer needed. The Provider must maintain documentation of privileged staff access, authentication requirements, account lifecycle, access reviews and available evidence for the standard service. Application-level customer permissions alone do not prove personnel-access controls across every supplier. Additional customer-specific requirements may be recorded in an optional enterprise schedule.

Document workflows provide classification, access and approval controls. Approved selection limits which private documents are used in a task; public-source queries have a separate purpose. Available controls do not guarantee automatic identification or removal of all sensitive information in files or free-text prompts. Customer instructions and appropriate classification remain necessary.

Selected organisation actions generate audit metadata identifying activity and time. This is not represented as an immutable evidential log or a complete recording of every administrative action. Optional analytics exclude question text, answer text, document content and search terms and are off until consent. Necessary billing, usage and security records are separate. AI requests disable provider response storage, without a zero-retention claim.

Personal and authorised organisation exports provide structured application records. Original-file downloads and supported report exports are separate functions; the Export and Switching document identifies formats and limitations. Deletion controls remove selected active content. Organisation retention cleanup is initiated by an authorised administrator; merely configuring a period does not schedule automatic deletion.

Personal account deletion requires resolution of organisation membership or ownership. Removal of the linked authentication identity may need administrator completion. A complete deletion assessment must include active data, derived records, identity data, supplier copies, legal holds and backup expiry. Standard DPA Schedule D governs by default; the Provider must supply applicable lifecycle and completion information. Additional deployment-specific retention requirements may be agreed separately.

The Provider must document and maintain appropriate controls for encryption in transit and at rest, key management, network boundaries, infrastructure administration, secret storage and rotation, software review, dependency and vulnerability management, change approval and rollback. Evidence of the actual configuration must be available for the review required by the DPA; this is a Provider obligation for the service, not a requirement that every Customer negotiate a separate Schedule B. This public document does not assert a particular encryption algorithm, customer-managed key capability, penetration-test outcome or vulnerability-remediation time that has not been established for the deployment.

Security changes must be assessed against the agreed risk and protection level. Secrets must not be submitted in user prompts or public support forms. Detailed architecture and evidence may be reviewed under appropriate confidentiality arrangements; confidentiality must not prevent required customer or supervisory review.

The DPA requires confidentiality for authorised personnel, appropriate access limits, control of subprocessors, notification without undue delay of personal-data breaches, assistance and audit cooperation. The Provider must maintain responsible incident contacts, escalation and evidence-preservation procedures, monitoring responsibilities, personnel measures and supplier oversight for the standard service. An optional enterprise schedule may add customer-specific requirements. No unverified round-the-clock response or fixed incident SLA is implied.

Backup scope, frequency, isolation, restoration tests, resilience, disaster recovery and business continuity must be evidenced and agreed where the intended use requires them. Recovery time and recovery point objectives are contractual only when expressly specified and accepted; no default numerical RTO, RPO or uptime percentage is stated here.

Before a controlled deployment, the parties record the applicable measures, their versions, available evidence, unresolved gaps and who owns each action. A gap material to the intended data must be resolved or that processing excluded. Changes must not materially reduce the agreed protection and follow DPA section 3. Audit access and mandatory supervisory rights follow DPA section 8.