| Purpose | Delivery of the Exceptao GRC platform to Tenant organisations: provisioning tenant accounts, authenticating and authorising users, executing workflow logic, generating the audit log, producing reports and exports, and storing evidence attached to controls and exceptions. |
| Legal basis | Art. 6(1)(b) GDPR — necessary for performance of the subscription contract with the Tenant. The contract covers both the organisational Tenant and the individual Users it registers. |
| Categories of personal data | E-mail address; full name (optional); Argon2id password hash; TOTP secret, held as Fernet ciphertext (AES-128-CBC with HMAC-SHA256) and never written to the database in clear; WebAuthn credential ID, public key and signature counter; server-side session records; IP address and user-agent string recorded at authentication events; locale and timezone preference; role and permission assignments; billing contact details (company name, billing e-mail, tax registration number). |
| Categories of data subjects | Employees, contractors and agents of Tenant organisations registered as Users of the Service; Tenant billing contacts. |
| Recipients | Operator staff with production access (MFA-gated, audit-logged, need-to-know); Cloudflare, Inc. (CDN, WAF and Tunnel — IP addresses and request headers transit the edge; evidence objects are stored in Cloudflare R2); Microsoft Corporation (outbound notification e-mail via the Graph API, and cryptographic key custody in Azure Key Vault). The complete list, with transfer mechanisms, is at /legal/subprocessors. |
| Storage location and region | EU/EEA — Poland. The Exceptao production host is a VPS operated by OVH Sp. z o. o., the Polish OVHcloud entity (not the French parent, OVH SAS), on the VPS-WAW2 (Warsaw 2) network. Evidence class: the Warsaw location is established from RIPE registry netname and geoloc, corroborated by reverse DNS; that is registry metadata and not a contractual attestation from the provider, and confirmation in the provider’s own control panel is outstanding. The country of hosting (PL) is not in doubt. The Exceptao deployment is a physically and logically separate host, database and secret store from the paraKSCol / CyberZgodność EDU deployment. |
| Retention period | Account and user data: duration of the Tenant subscription plus 30 days after termination. Billing contact data: 5 years from the end of the billing period (Polish Accounting Act, Art. 74(2)). Server-side session records: a session expires 8 hours after it is created; expired session rows are deleted by a scheduled job that runs daily at 04:30 UTC and writes its own audit entry. There is no idle-timeout: the 8 hours run from creation, not from last activity. |
| International transfers | No customer business data leaves the EU/EEA. Several subprocessors are US-incorporated; each is engaged under Standard Contractual Clauses with the processing itself performed in an EU region. Per-subprocessor detail at /legal/subprocessors. |
| Technical and organisational measures | Argon2id password hashing at memory 100 MiB, time cost 3, parallelism 8. Multi-factor authentication is mandatory for every account holding a local password and is enforced by middleware: until such an account enrols a TOTP authenticator or a WebAuthn passkey, every authenticated API call other than enrolment is refused. Accounts that sign in through a Tenant’s own identity provider hold no local password and are governed by that provider. Login throttling locks out after 5 consecutive failures, keyed on both username and source IP, for 15 minutes. Tenant isolation is enforced by PostgreSQL FORCE ROW LEVEL SECURITY with the request running under a non-superuser, NOBYPASSRLS role. The data volume carrying the database and every container’s state is LUKS-encrypted and unlocked at boot from network-bound Tang servers, so no passphrase is stored on the box. Sensitive credential columns are Fernet ciphertext under a platform-wide key held in HashiCorp Vault’s KV store; per-tenant data encryption keys are designed and not built. TLS in transit, terminated at the Cloudflare edge; the negotiated minimum is an edge configuration rather than an application setting, and is stated at /legal/security §6.1. Session cookie Secure; HttpOnly; SameSite=Lax. Evidence objects in Cloudflare R2 are served through pre-signed URLs valid for 15 minutes. |
| DPIA required | No — standard B2B SaaS account management; no special-category data; no public-authority processing at scale. Reviewed annually. |
| Purpose | Maintaining a tamper-evident, append-only audit log per Tenant in order to (a) support the Tenant’s own compliance obligations (NIS2 Art. 21, ISO/IEC 27001, SOC 2, internal policy); (b) enable security incident investigation; (c) give auditors and regulators verifiable evidence of what was done inside the Tenant’s workspace; and (d) discharge the Operator’s own architectural commitment that significant actions are logged and the log cannot be silently rewritten. |
| Legal basis | Art. 6(1)(f) GDPR — legitimate interest. |
| Legitimate interest assessment | Purpose: the Operator has a genuine interest in the audit chain both as the core product commitment and as a security control; Tenants have a genuine interest in a record of actions they can verify without trusting the Operator. Necessity: an actor-attributed, hash-chained log is the minimum that achieves this — an unattributed log supports neither incident investigation nor regulatory evidence. Balance: data subjects are acting in a professional capacity inside a compliance tool their employer adopted for exactly this purpose; what is recorded is an action record rather than message content; access is scoped to the Tenant’s own chain; and erasure is honoured by pseudonymisation of the identity the row resolves to. The Operator considers the balance to favour processing. One element of this assessment is open and is recorded as such: actor IP address and user-agent string cannot be removed later, for the structural reason set out in the retention row. That specific point is in the legal-review queue as item L4. |
| Categories of personal data | Actor user ID; actor IP address; actor user-agent string; action code (real examples: exception.transition.approve, risk.create, incident.create, controls.evidence.upload, audit.chain.verified); target object type and ID; before/after state summaries, which carry field-level changes rather than document content; request ID; timestamp; chain position; SHA-256 row hash and the preceding row’s hash; the canonical-form contract version. |
| Categories of data subjects | Users of the Service acting in a professional capacity within their Tenant’s workspace. |
| Recipients | The Tenant’s own users holding the auditor role (read-only, scoped by row-level security to that Tenant’s chain); the Operator’s platform-administration console, whose every write is itself audit-logged under the operator’s identity; competent supervisory authorities on request. |
| Storage location and region | As PA-001. |
| Retention period | Lifetime of the Tenant account. This is a statement of what the system does, not a target. DELETE and TRUNCATE on the audit table are refused by a database trigger for every role including superusers, no application role holds either privilege, and no purge job exists. Removing a row would invalidate the hash of every row after it and every timestamp anchor taken over the old chain head, so a rolling-window purge is not something that could be added without abandoning the tamper-evidence property. Applicable law may independently require longer retention of particular records (for example billing-related entries under the Polish Accounting Act). |
| Erasure | On a verified Art. 17 request the user record is pseudonymised in place: the e-mail address becomes a stable tombstone of the form deleted-<uuid>@tombstone.invalid, the name is cleared, the TOTP secret is destroyed and the account is deactivated. The operation is idempotent. Audit rows reference the user by internal identifier and never by e-mail address, so every later view of a historical row resolves to the tombstone and no audit row is rewritten — the chain is preserved by construction rather than recomputed. The actor IP address and user-agent string recorded on those rows are not pseudonymised and persist for the lifetime of the Tenant account. |
| International transfers | None beyond the PA-001 scope. |
| Technical and organisational measures | The PostgreSQL role that writes the audit log holds INSERT and SELECT on the audit table and no UPDATE, DELETE or TRUNCATE; the SELECT is required because the chain trigger must read the current head to compute the previous hash. A regression test asserts that privilege set exactly, on every pull request. The row hash is sha256(prev_hash || canonical(row)), where the canonical form is twelve fields joined by the ASCII unit separator 0x1f and rendered by PostgreSQL’s own text output — deterministic for a given PostgreSQL major version. It is not RFC 8785 / JCS canonical JSON. The hash is computed by a database trigger under an advisory lock, not by the application, and the application is forbidden from supplying the hash or the chain position. The chain is linked and walked by chain position, never by timestamp, so a backdated row still appends rather than reporting a false discontinuity. RFC 3161 timestamp anchors over the chain head are taken on a 24-hour interval and re-verified on a 7-day interval; both are worker intervals rather than wall-clock schedules, so they restart with the worker. A full chain walk runs daily at 02:00 UTC. Any Tenant may verify on demand at GET /api/audit/verify/, which returns the row count on a clean chain and HTTP 422 with the first broken position otherwise. |
| DPIA required | Recommended, and not yet completed. The combination of indefinite retention of actor IP and user agent with an erasure mechanism that pseudonymises rather than deletes is the kind of carve-out that should be written up and assessed rather than asserted. Recorded as an open item. |
| Purpose | Invoicing Tenant organisations for subscription fees; tracking subscription status, tier and module entitlements; recording usage metrics that feed billing; keeping the financial records Polish law requires of the Operator. |
| Legal basis | Art. 6(1)(b) GDPR — performance of the subscription contract; Art. 6(1)(c) GDPR — legal obligation (Polish Accounting Act; Polish VAT Act). |
| Categories of personal data | Billing contact name and e-mail address; company name and registration identifiers (where the Tenant is a sole trader these identify a natural person); VAT number; invoice correspondence; payment status records. |
| Categories of data subjects | Tenant billing contacts — typically finance, procurement or management staff. Where the Tenant is a sole trader, the Tenant themselves. |
| Recipients | Operator finance and administration staff, under a role-restricted permission; the Polish tax authority where a legal obligation applies. Stripe, Inc. is implemented in the platform but is listed as a planned and not-yet-active subprocessor; Tenants are notified at least 30 days before any activation, per DPA §6.2. |
| Storage location and region | Billing records in the platform database, EU/EEA — Poland, as PA-001. Accounting documents outside the platform: [TO BE COMPLETED: confirm document storage location and format — paper / cloud accounting software]. |
| Retention period | 5 years from the end of the applicable billing period, under the Polish Accounting Act, Art. 74(2). |
| International transfers | None at present. If Stripe is activated, Standard Contractual Clauses will be in place and this record will be updated before, not after. |
| Technical and organisational measures | Billing data is reachable only through a role carrying the finance permissions; the platform-administration console writes an audit row for every mutation, on success and on failure; at-rest encryption as PA-001. |
| DPIA required | No — ordinary business invoicing; no special-category data. |
| Purpose | Receiving and answering inbound enquiries; running product demonstrations; following up with prospective customers; sending requested product information and trial invitations; managing the sales pipeline; and recording marketing-communication consent and its withdrawal. |
| Legal basis | Art. 6(1)(f) GDPR — legitimate interest in pursuing a commercial relationship with an organisation that has itself made contact, asked for a demonstration or requested a trial. Art. 6(1)(a) GDPR — consent, for marketing communications that are not a reply to an enquiry. |
| Categories of personal data | Name; e-mail address; job title and seniority; organisation name and sector; telephone number where volunteered; notes from calls, e-mail exchanges and demonstrations; product interest area; trial account activity where a trial is issued; marketing-consent status and its history. |
| Categories of data subjects | Individuals who contact the Operator through the marketing site, e-mail, telephone or at an event; individuals who accept a trial. Typically security engineers, CISOs, compliance officers and IT administrators at target organisations. |
| Recipients | Operator sales and marketing staff; [TO BE COMPLETED: name of CRM tool used by the Operator — to be documented when selected and confirmed]. No prospect data is disclosed to any third party for that third party’s own marketing purposes. |
| Storage location and region | [TO BE COMPLETED: CRM tool storage location — must be EU/EEA or SCC-covered]. This activity is outside the platform: no CRM or marketing-consent store exists in the Service, and prospect records are therefore not held under the technical measures described in PA-001. |
| Retention period | 24 months from the last substantive contact. A re-confirmation is sent at 18 months; where there is no response within 30 days the record is deleted. Immediate deletion on request. Marketing-consent evidence is retained for 3 years after consent is withdrawn, for the sole purpose of demonstrating the basis on which the communications were sent. |
| International transfers | [TO BE COMPLETED: depends on CRM tool selected — must have an SCC or adequacy basis if outside the EU/EEA]. |
| Technical and organisational measures | Access restricted to sales and marketing staff. Prospect data is not combined with Tenant Service Data, and the platform holds no prospect records. |
| DPIA required | No — ordinary B2B sales engagement; no special-category data; no automated decision-making. |
| Purpose | Detecting, triaging and responding to security incidents, abuse of the Service and anomalous behaviour; protecting the Service and every Tenant on it; meeting the Operator’s security obligations under the DPA and the Security Whitepaper. |
| Legal basis | Art. 6(1)(f) GDPR — legitimate interest. The Operator runs a multi-tenant platform holding other organisations’ compliance data; every Tenant benefits from the monitoring, and a user of a security product would expect it. |
| Categories of personal data | IP addresses and user-agent strings of authentication attempts, successful and failed; timestamps of authentication events; failed MFA attempts; lockout events; passkey signature-counter anomalies; audit-chain verification outcomes and chain-break alerts; backup, restore-drill and recovery event metadata, which contains no customer business content. |
| Categories of data subjects | All Users of the Service, and any person who attempts unauthorised access. |
| Recipients | Operator on-call and incident-response personnel; law enforcement only where a legal obligation applies and with documented justification; competent supervisory authorities where a legal obligation applies. |
| Storage location and region | As PA-001. Security events are recorded in the same append-only audit store as PA-002 and in the application’s container logs on the same host. No third-party log-aggregation or error-tracking service is in use. An error-tracking service appears on the subprocessor list as planned and not active; if one is adopted, this record and /legal/subprocessors are updated before it is switched on. |
| Retention period | Lifetime of the Tenant account for the events written to the audit chain, for the structural reason given in PA-002. Container logs are held on the host and rotate with the host’s log rotation; they are not a record the Operator undertakes to retain or to purge on a defined cycle, and no retention period is published for them because no code enforces one. Incident records relating to a confirmed breach or a live legal claim are kept at least until the matter closes. |
| International transfers | None. |
| Technical and organisational measures | Login throttling (5 failures per account or per source IP, 15-minute lockout, reset on success). Rate throttling on the audit-verification endpoint. Mandatory-MFA middleware, which refuses every authenticated API call from an account with no second factor. WebAuthn signature-counter validation, with automatic credential revocation on a counter regression. A daily audit-chain walk that raises an alert on a break, and which fails loudly rather than silently when it cannot notify. Edge controls (WAF rule sets, bot management, rate limiting on authentication endpoints) are operated at Cloudflare and are described in the Security Whitepaper at /legal/security. |
| DPIA required | No — security monitoring of a professional-context service; no special-category data; no automated decision producing legal effects. This would need revisiting if behavioural or AI-based anomaly scoring were introduced. |
| Purpose | Sending transactional and service e-mail on behalf of the platform’s workflow engine (exception approvals and rejections, incident deadline warnings, overdue-task alerts, invitations, password resets); service announcements (planned maintenance, terms changes); and critical security notices (breach notification, account compromise). Marketing communications are not sent by the platform and are covered by PA-004. |
| Legal basis | Art. 6(1)(b) GDPR — contract, for workflow notifications required to operate the Service. Art. 6(1)(f) GDPR — legitimate interest, for service announcements and security notices, which a User has a legitimate expectation of receiving. |
| Categories of personal data | Recipient e-mail address; recipient display name, for the salutation; notification content — the title of the item, the action required, the due date or deadline and a link back into the Service. Notification content does not carry audit log contents, evidence file contents, or the full text of an exception, risk or incident description. |
| Categories of data subjects | Users with notifications enabled; Tenant Admin contacts for service announcements and security notices. |
| Recipients | Microsoft Corporation, via the Microsoft Graph API. Under “Model A” the message is sent from the Operator’s own Microsoft 365 tenant, configured for EU data residency. Where a Tenant has connected its own mailbox (“Model B”), the message is sent through the Tenant’s own Microsoft subscription and Microsoft processes it under the Tenant’s own agreement with Microsoft rather than under this record. |
| Transport | The Graph HTTPS API. There is no SMTP send path in the platform. Where no Graph connection is configured the message is written to the application log and not sent — a deliberate fail-visible rather than a silent drop. |
| Storage location and region | Message bodies are rendered in memory on the EU host at send time. The platform persists no send-status records — there is no notification table, and therefore no stored delivery log to retain, disclose or purge. Where a notification is a side effect of a workflow transition, the transition itself is recorded in the audit chain under PA-002; the message body is not. |
| Retention period | Not applicable to this activity, for the reason in the row above. The audit-chain record of the triggering workflow transition is retained under PA-002. |
| International transfers | Microsoft Corporation is US-incorporated; processing takes place in the EU Microsoft 365 tenant, under Standard Contractual Clauses in the Microsoft Online Services Data Processing Addendum. |
| Technical and organisational measures | TLS in transit to the Graph endpoint. The Graph OAuth token is stored as Fernet ciphertext in the database under a key held in Vault’s KV store, refreshed by a scheduled job, and a token that cannot be decrypted is reported rather than treated as expired. SPF, DKIM and DMARC are published for the Exceptao sending domain; the DMARC policy is currently p=quarantine; pct=10 and is being raised on a staged ladder rather than being at p=reject today. E-mail to demonstration tenants is suppressed at the dispatcher. |
| DPIA required | No — transactional e-mail; no special-category data; no profiling. |
| Ref | Activity | Legal basis | Retention | DPIA |
|---|---|---|---|---|
| PA-001 | Platform delivery and user management | Art. 6(1)(b) contract | Subscription + 30 days; billing contacts 5 years; session rows expire at 8 hours and are swept daily | No |
| PA-002 | Audit log integrity | Art. 6(1)(f) legitimate interest | Lifetime of the Tenant account — deletion is refused at database level | Recommended, outstanding |
| PA-003 | Billing and subscription | Art. 6(1)(b) + Art. 6(1)(c) | 5 years | No |
| PA-004 | Prospective customer engagement | Art. 6(1)(f) + Art. 6(1)(a) | 24 months from last contact; consent evidence 3 years after withdrawal | No |
| PA-005 | Security monitoring | Art. 6(1)(f) legitimate interest | Lifetime of the Tenant account for chained events; no published period for host logs | No — revisit if anomaly scoring is added |
| PA-006 | Outbound notification e-mail | Art. 6(1)(b) + Art. 6(1)(f) | No send-status records are kept | No |
The retention column above is the same answer as each activity’s own retention row, deliberately. An Art. 30 record that summarises itself differently from its own body is the defect this table exists to avoid.
| Privacy and data protection | privacy@exceptao.com |
| Security disclosures | security@exceptao.com |
| Supervisory authority | Urząd Ochrony Danych Osobowych (UODO), Warsaw, Poland — uodo.gov.pl. The Operator is established in Poland; a data subject may also complain to the supervisory authority of their own habitual residence or place of work. |