DPA Annex II — Technical and Organisational Measures

This Annex forms part of the Data Processing Agreement and describes the technical and organisational measures Scalign AS applies as Data Processor (GDPR Art. 32).

1. Encryption

In transit: all traffic is encrypted with TLS 1.2+, enforced at the edge (HSTS). All internal service-to-service traffic is also TLS — there is no private unencrypted network.

At rest: AES-256 across all Scalign-operated stores — the primary database, its backups, the object store, and the cache; sub-processors encrypt at rest per their published standards. Meeting transcripts are additionally encrypted at the application layer (AES-256-GCM) before storage; the tenant identifier is bound into each ciphertext's authentication tag as additional authenticated data, so a ciphertext presented in the context of another tenant fails integrity verification. Credentials for customer-enabled integrations (OAuth tokens and API keys) are likewise sealed at the application layer under a separate key, bound to the owning user, and never stored in plaintext.

Keys are provider-managed; customer-managed keys are not offered. The application-layer transcript key is restricted to personnel with production access (MFA-enforced). There is no fixed rotation schedule; on suspicion of compromise the key is replaced and stored ciphertexts are re-encrypted under the new key.

2. Access control

In-product: role-based access control (owner / admin / member) enforced server-side on every API call, plus per-recording visibility controls and explicit share grants.

Internal: least privilege — access to customer data is limited to personnel with an operational need, and production console access to the personnel who operate production. MFA is enforced on all internal accounts, cloud consoles, and the code repository. Access occurs via provider consoles (logged at the provider level) and an internal administration application restricted to Scalign staff accounts on a separate origin. On departure, access is revoked the same day.

3. Confidentiality of personnel

All personnel are bound by strict confidentiality obligations in their employment contracts, covering customer data and surviving termination, backed by the Norwegian Penal Code §§ 209–210 and the Trade Secrecy Act §§ 9–10. All personnel are subject to Scalign's written information security policy, which governs device security, access, and customer data handling.

4. Pseudonymisation and minimisation

Data is not pseudonymised at rest; the compensating control is application-layer encryption of transcripts with tenant binding. Speaker attribution does not process biometric data: online meetings use participant identity supplied by the meeting platform; in-person recordings are separated by voice into anonymous speaker labels within that single recording only, and no voiceprint, speaker embedding, or other voice-derived data is created, stored, or matched across recordings. LLM prompts, which carry transcripts, are never recorded in error tracking or telemetry; outputs of tool-less model calls are recorded in EU error-monitoring traces for debugging. AI providers operate under API terms that exclude training on customer data, with only transient provider-side retention. Recording-ready notification emails carry an AI-generated meeting summary and next steps in the body; that derived content is held in the transactional email provider's (Postmark, US) message log for its 45-day retention window. Full transcripts are never emailed, and notifications can be disabled per member.

5. Integrity and secure development

Development, staging, and production are separated environments; the staging environment uses a production clone protected by the same safeguards (encryption, access control, MFA) and accessed by the same personnel. Every production change requires a reviewed pull request with CI gates (build, type checks, lint). Dependency and vulnerability scanning (Dependabot) and static analysis (CodeQL) run continuously. Change management is PR-based with these gates.

6. Availability and resilience

Hosting is serverless and multi-AZ by design (Vercel), with the database in AWS eu-central-1 (Frankfurt) on separated multi-AZ storage. Backups: automated daily encrypted database dumps to an EU-region Google Cloud Storage bucket, retained 35 days, plus provider point-in-time recovery (1-day window). Object-store content (encrypted transcripts) relies on the provider's replicated, durable storage and is not included in the dump job. A documented disaster-recovery plan defines RPO ≤ 24 hours and RTO ≤ 8 hours.

7. Restore and recoverability

Backup restores are tested by restoring database dumps to an isolated environment. A full production-environment restore drill is planned under the DR plan and has not yet been performed.

8. Testing and evaluation of effectiveness

Penetration testing is external and continuous: Heist Security performs automated monthly assessments (OWASP ASVS 5.0 and OWASP Top 10) covering the web application and all APIs. Findings are remediated continuously as reports land; a summary of the latest report is available on request. Vulnerability scanning is continuous via Dependabot and CodeQL.

9. Logging and monitoring

Security-relevant events are monitored via error and performance monitoring (EU, with PII scrubbing), platform request logs, background-job logs, and real-time alerting. Access to customer data occurs through provider consoles and is captured in provider-side access and query logs. Log retention is up to approximately 90 days, depending on the provider; all log stores sit behind MFA-enforced consoles and are managed by the respective providers.

10. Incident response

A documented incident response plan defines a named Incident Lead, an accountable executive for external communication, a response process, a containment playbook, and an external intake address (security@scalign.ai). Personal-data breaches are notified to the controller without undue delay and in any event within 72 hours of confirmed awareness, with the information the controller needs for its own notification obligations. Post-incident reviews are conducted after significant incidents.

11. Sub-processor management

All sub-processors are bound by data-processing agreements with obligations consistent with this DPA. Scalign holds the controller's general written authorization, and publishes a current sub-processor list; controllers can request email notification of changes and have a right to object. Transfers outside the EEA are covered by SCCs or an adequacy decision. Before a new sub-processor touches personal data, Scalign reviews its security certifications (SOC 2 Type II and/or ISO 27001), its GDPR terms (DPA with SCCs where applicable, processing locations, retention and deletion, and its own sub-processor list), and, for AI providers, its commitment not to train on customer data.

12. Data segregation

Tenants are logically separated by tenant-ID scoping: every tenant table carries a workspace ID and every API procedure resolves workspace membership before any query. Transcripts add cryptographic tenant binding: the tenant identifier is authenticated into each ciphertext, so decryption in the context of another tenant fails integrity verification. Separation is tested in the monthly external penetration tests using dedicated cross-workspace accounts, with no findings.

13. Physical security

Inherited from the underlying EU cloud providers (AWS and Google Cloud), which hold SOC 2 Type II and/or ISO 27001. Scalign operates no data centres of its own.

14. Data retention and deletion

Personal data is retained for the duration of the customer relationship. Customers can request deletion of their data at any time, and on termination all personal data is returned or deleted at the controller's choice. In-product deletion removes data from active use immediately. To protect against accidental loss, deleted meeting recordings are permanently erased after 24 hours and deleted workspaces after 14 days; within that window the customer can request restoration or earlier erasure. Full purge across Scalign's systems and relevant sub-processors is completed as a managed deletion process within 30 days of the request. Deleted database data ages out of encrypted backups within 42 days. Transcript data is stored only as AES-256-GCM ciphertext.