What should you ask before signing anything?

If your vendor stopped tomorrow, who would still have access to your data, your accounts, and your exports? That is the right question, because the risk is not only leakage: it is access that outlives the contract, team changes, and end-of-service mistakes.

Under the GDPR, a processor must handle personal data only on documented instructions from the controller and the contract must frame security, confidentiality, and end-of-service duties, as summarized by the CNIL in its controller/processor guidance and its processor guide.

For an SME, the smart goal is not a “perfect” contract but a controllable exit. If you can answer three questions — who has access, how access is removed, how deletion is completed — you have already reduced most of the headaches.

  • Who has named access or shared access?
  • Which access rights are temporary, and until when?
  • What must be deleted, returned, or archived at the end?

The 4-lock method: identity, privilege, duration, evidence

Lock one: identity. The CNIL recommends requiring authentication before any access to personal data and managing differentiated permissions according to need. Least privilege limits damage if a account is compromised or misused.

Lock two: privilege. Separate read, export, edit, and delete rights. A support vendor usually does not need delete rights in production. An integrator does not need permanent access. An intervention log, as recommended by the CNIL for maintenance, helps create a usable trail.

Lock three: duration. Open access on request and for a predefined period, then close it automatically. This applies to remote maintenance as much as to one-off projects.

  • Create named accounts, never a permanent generic “vendor admin”.
  • Set an expiry date when access is opened.
  • Log every intervention that matters for auditability.

Contractual exit: what deletion should cover

Offboarding is not just clicking “disable account.” The CNIL draft reference framework for processor GDPR certification describes a stricter logic: permanently delete the data when the service ends, including data held by downstream processors, using measures appropriate to the medium and context.

The CNIL also recommends a secure deletion procedure and secure erasure of storage media before disposal or return. For an SME, that means distinguishing three objects: live data, working copies, and technical traces or backups whose fate must be expressly defined.

Important limitation: not all deletion is instantaneous. Some backups are frozen for a defined period; some logs must be retained for security or evidence. The point is therefore not “delete everything now,” but document what is deleted, what is kept, where, and for how long.

  • Write in the contract the return or deletion of working data.
  • Request a deletion certificate or attestation when relevant.
  • Describe how backups, logs, and local copies are handled.

Fictional numerical example: one marketing vendor, three access zones

Fictional example: an SME outsources its customer database to a marketing vendor for 90 days. The vendor has 24 staff, but only 6 need named access to the tool. The SME creates 6 accounts with read-and-export rights, 1 internal admin account, and a 14-day temporary access window for the integrator during initial setup.

On day 91, the SME removes the 6 vendor accounts, retrieves the return export, gets confirmation that local copies were deleted, and asks for a list of places where data may have been stored. In this scenario, the practical gain is not “more security” in the abstract: it is avoiding a shared account staying alive, an export sitting on a laptop, or a team wrongly believing “the vendor deleted everything.”

That is where many firms miss the mark: they think about confidentiality during the project, but not about the final teardown. Yet the exit must be designed from the start.

  • 1 vendor = 1 documented access perimeter.
  • Temporary access must expire without manual intervention.
  • Deletion evidence should cover systems, endpoints, and relevant backups.

Seven-day action checklist

Day 1: map the vendors that touch data. Owner: DPO or managing director. Observable result: one master list of vendors with data type and systems involved.

Day 2: classify current access. Owner: IT manager. Observable result: named, shared, temporary, and inactive accounts identified.

Day 3: remove or reduce unnecessary rights. Owner: IT + business lead. Observable result: an updated permission matrix, with read/write/delete separated.

  • Day 4: add access duration and end date to every live contract. Owner: procurement/legal. Observable result: traced clauses or addenda.
  • Day 5: define the end-of-service deletion procedure. Owner: security/IT. Observable result: a written erasure-and-return runbook.
  • Day 6: prepare the deletion attestation template. Owner: DPO/legal. Observable result: a ready-to-send document.
  • Day 7: run a real or simulated vendor exit. Owner: CEO or security lead. Observable result: accounts closed, data returned or deleted, written evidence archived.