How do you share sensitive data with partners, and end access when the project ends?

A bank wants to know why some customers leave. A health agency wants to know who waits longest for treatment. Either way, the project needs records from your systems, and three outside parties need them: a university research team, a partner organisation and an analytics contractor.

Someone prepares an extract: a few hundred thousand rows, with ID numbers, dates of birth, postcodes and account or case numbers. Each partner asks for slightly different fields, and it is faster to send everyone the same file. It goes by secure file transfer, with a data sharing agreement attached.

The project ends. The agreement says the data must be deleted. The researcher has moved to another university. The contractor has reassigned the team. Nobody has asked you to check, and you have no way to.

It is quicker to send all the columns than to cut a version for each partner, so everyone holds the ID numbers. The file then sits in downloads, shared drives and analysts’ working folders.

Researchers change jobs and contractors rotate staff. You cannot say who opened the file, or whether it is still in use.

Sensitive records about your customers or citizens are held by people who no longer need them, or who never should have had the ID column. You have an agreement you cannot enforce, and the people in the data, or a regulator, may hear about a breach before you do. And the next yes is harder, because data owners refuse to share when they cannot see where data ends up.

A data sharing agreement gives you a legal claim and a purpose, but nothing stops a copy being kept or passed on. De identification before sending removes direct identifiers, but it is done once for everyone and the data can still be sensitive in combination.

Secure file transfer covers the delivery, not what happens after the file arrives. A deletion clause with a signed confirmation gives you a statement, with no way to check it is true.

You register the dataset once, with the partners who may receive it. NakodaX does not store the data. It stays in your systems, and the files go from your systems to the partners’. If your rules say keys must stay in house, NakodaX can be installed on your own servers and works offline.

Each partner gets a file with only the columns it may see. The researchers get no ID column at all: it is not in their file, not hidden by software on their machine. The contractor can get the ID sealed, so they can match records in their own tools without ever reading the values.

Each partner has its own licence, set to the dates of the agreement, with an optional limit on how many times a file can be opened. One partner can change or end without touching the others. When the project ends, or a partner is stopped early, you end that licence and NakodaX stops releasing the key, within the hour even for a long running job.

Every read and every refusal is logged, so you can see who opened what and when. A partner who needs another column or more time files a request over the licence it already holds, and extending time needs a second approver.

A partner who already opened a file keeps what they opened. Ending access stops the next key request and does not reach data already read, which is why each partner’s view holds only what it needs. The data is not destroyed when access ends: NakodaX refuses to release the key, and the files stay in your systems until you remove them.

The cut by rows is made by your own query or the NakodaX library before the file is protected. NakodaX never sees your data, so it cannot check that the right rows were left out. Columns are checked. Partners need a licence key and the NakodaX library, or the browser reader in the console.