GDPR: subject requests, export and erasure

Two operations sit behind the GDPR obligations that touch this platform: an export and an erasure. Both are organisation-scoped, and understanding that scope is the most important thing in this article, because it determines how each one can honestly be used.

What the export produces

An export streams a JSON attachment. The filename carries the organisation identifier, so a file sitting in a downloads folder six months later is still identifiable:

attachment; filename="gdpr-export-{organisation}.json"

The payload carries the organisation identifier and an export timestamp, followed by four collections.

Note what is not in that list, because a reviewer will notice. The export is scoped to the account and session records above; it is not a complete dump of every log line the SIEM has ingested about a person's sign-ins. Security event data has its own retention model, described further down, and its handling under Article 15 is a question about your own lawful basis for security monitoring rather than about an export button.

The same fix stopped the export swallowing collection failures. Two extra keys now appear at the top level whenever something could not be gathered, and they are the first thing to look at before you use a file for anything:

"complete": true                     // every collection was gathered

// or, when something failed:
"complete": false,
"incomplete": { "scim_users": "<the database error>" },
"incomplete_notice": "Some sections could not be gathered and are empty
  above, not absent because the tenant has no such records. Do not file
  this export as a complete response to a data subject access request
  until they are present."

A failed collection is emitted as an empty array rather than omitted, which is why the flag matters: an empty collection is indistinguishable from this organisation has none of these without it. A partial export is still useful — a regulator would rather have three collections and an honest note than a server error — and it must not be filed as a complete response while complete is false.

Answering a subject access request with it

1. 1

   Verify the requester before you export anything

   An unverified subject access request is an attractive way to obtain a list of your staff and their email addresses. Verification is your responsibility as controller, and it happens before any data is produced, not after.

2. 2

   Record the request and the clock

   One month to respond, extendable by two further months for complex requests with the subject informed of the extension. Log the receipt date somewhere that is not one person's inbox.

3. 3

   Produce the export

   The export is organisation-wide, so treat the file as internal working material from the moment it exists. Do not forward it. It contains other people's personal data.

4. 4

   Extract only the requesting individual's records

   This is manual, and it should be. Filter to the subject's own user record, their provisioned-user record and their AI sessions, and check each field before it leaves your organisation.

5. 5

   Consider the other controllers in the picture

   For an organisation using Microsoft 365, a substantial part of the personal data a subject may ask about lives in Microsoft's services rather than here. See Permissions we request for what this platform reads, which is the honest boundary of what it can be asked to produce.

6. 6

   Delete the working copy

   The full-organisation export you produced as source material has served its purpose once the response is sent. Keeping it is a data minimisation failure of your own making.

Erasure: exactly what it removes, and in what order

Erasure cascades across every organisation-scoped record and finishes with the organisation itself. The order is not arbitrary — dependent records are removed before the rows they reference, so the operation does not fail partway through on a foreign key.

The whole cascade runs inside a single transaction with a 60-second timeout, and returns no content on success. Two properties follow from that, and both are worth stating to a reviewer. Because it is transactional, a failure at step six does not leave you with an organisation whose AI history has been deleted and whose connectors have not — the transaction rolls back and nothing is removed. And because it returns no content, a successful erasure is silent by design: there is no residual response body describing what was deleted, because such a body would itself be a record of the data you had committed to remove.

One further honest note on scope. The cascade covers organisation-scoped tables in the platform's own database. Backups exist, they are encrypted before upload, and they age out under their own schedule — so an erasure is a deletion from the live system at the moment it runs, and your retention documentation should describe the backup horizon separately rather than implying instantaneous global destruction.

Records of processing and impact assessments

Your records of processing activities and your data protection impact assessment entries are held on the platform and are exported, as they stood at report time, in the GDPR section of the evidence bundle. That makes them part of the same hash-stamped artefact as the NIS2 control results, which is usually what a reviewer asking about both wants. See The evidence bundle for how the hash and the chain-of-custody stamp work.

The platform stores those records and includes them in the export. It does not write them for you, and it does not assess whether a given processing activity required an impact assessment. Those are controller judgements.

Why a record shows as three of eight

Article 30(1) enumerates the elements a record of processing must contain. The register stores them as separate fields rather than as one block of prose, and shows how many of them each record actually states. A record giving three of the eight is saved, versioned and listed — you must be able to assemble one over several sittings — and it is labelled as partial, with the missing elements named by their article.

This is deliberate and it is the difference between a register and a filing cabinet. Free text can hold three elements and look identical to text holding all eight, so a form over a single prose field would have let you file a partial record believing it complete. The completeness verdict travels with the record everywhere it appears — the register, the API and the evidence bundle — so those three cannot disagree about the same record.

• Elements (e), (f) and (g) are qualified in the Regulation by where applicable or where possible. They are still counted, because “this processing involves no third-country transfer” is a statement the register should carry, not a silence you leave the reader to interpret. Writing None in the field satisfies the element; leaving it blank does not.
• The lawful basis is reported separately and never counted among the eight. It is not an Article 30(1) element, but a record that does not name its Article 6 ground is unusable in the conversation the record exists for.
• Nothing is pre-filled. The platform knows its own retention periods and could guess at the data categories, but a record of processing is your statement about your processing, and a guess pre-filled into a regulator-facing document is a claim you did not make.

The register evaluates the Article 36 trigger

The DPIA register asks two risk questions because they are different questions. Article 35(1) high risk is whether the processing requires an assessment at all. Residual risk is what remains after the measures you recorded under 35(7)(d). A register that asks only the first cannot see the Article 36 trigger.

Where a DPIA indicates a high risk that your measures do not mitigate, Article 36(1) requires you to consult the supervisory authority before processing. That condition is computable from two fields, so the register computes it: an assessment recording a high residual risk with no consultation recorded is shown as an outstanding legal duty, cited to Article 36(1), on the row and in a notice when you save it. Storing the assessment and staying quiet about the duty it establishes would be a register that knows and does not say.

A residual risk of unassessed is also flagged, for the same reason: an assessment that has not reached a residual-risk conclusion cannot show whether Article 36 applies. It defaults to unassessed rather than low, so the register does not congratulate you the moment a row exists.

None of this is a legal conclusion about your processing. The platform does not decide whether an activity required an assessment, and it does not classify your risk — you do, and the register records what you decided and when the decision creates a duty you have not yet discharged.

Retention and data minimisation

Retention is per organisation and licence-driven, so the retention days value in your licence is a live setting rather than a marketing tier. Security event data has a more granular model, because a privileged administrative action and a bulk telemetry record should not be kept for the same period.

SIEM retention is configured per event classification, and each classification has separate hot, warm and archive periods, a flag for whether the warm tier stays searchable, and a flag for whether the archive is immutable.

The five event classifications are privileged_audit, detection, infrastructure, bulk_telemetry and forensic, and they drive both retention and replication priority. The distinction does the data minimisation work: bulk telemetry can be kept briefly because its value is immediate, while privileged audit and forensic records are the ones an incident report a month later depends on. Setting all five to the same long period is not caution, it is a minimisation problem you would have to defend.

Encryption facts you can cite

These are the answers to the questions a customer security questionnaire asks in this area, stated at the level of precision a reviewer can check.

• In transit: TLS 1.2 as the minimum, with 1.3 preferred.
• At rest, for privileged credential vaults: AES-256-GCM, using envelope encryption with a per-vault data key, and the key-encrypting key held in a managed key service.
• Passwords: hashed with bcrypt.
• API keys: stored as one-way hashes, so a key cannot be recovered from the platform — only rotated.
• Backups: encrypted before upload, under a key separate from production.
• Privileged actions: every one produces a hash-chained audit row, and chain verification locates the exact broken sequence number if a row is altered.

The AI processing answer

Three statements, taken from the AI system card, cover almost every AI question on a data protection questionnaire. No tenant data is used for training. Message retention follows your organisation's configured retention period. And the inference region is reported as unverified unless it has been explicitly configured — with the card noting that cloud providers may route inference outside the endpoint's region, and that where the provider offers no regional guarantee this is reported as unverified rather than claimed.

Do not let that third statement be rounded up when you answer a questionnaire. If your organisation requires a contractual guarantee that inference stays within the EU, the card is where you will see whether you have one, and the platform's assessment, detection and evidence functions all operate with the model features switched off.

What these operations do not do

• They do not make your organisation compliant. No software does. They produce the export, the erasure and the records your data protection audit asks for; the lawful basis, the assessments and the responses remain yours.
• They do not determine a lawful basis for any processing, including security monitoring — which is the basis most often queried and the one the platform depends on.
• They do not substitute for a processor agreement. The contractual layer is separate from the technical one.
• They do not filter by individual. Extraction of one subject's records from an organisation-wide export is manual, and it is manual because an automated filter that silently missed a table would be worse than no filter at all.

What to read next

1. The evidence bundle: what an auditor gets — where your records of processing and impact assessments are exported.
2. Roles and permissions — who in your organisation can run an export or an erasure.