How this handles your data

This is the Nextgen Recruiter applicant document check, built by Noorflows. This page says where data lives, who can reach it, what is kept, and — the part most pages leave out — which independent security reviews we have not had.

We hold no SOC 2 report, no ISO 27001 assessment, and no third-party security assessment of any kind. Nobody outside Noorflows has assessed these claims. If your procurement process requires one, we do not meet it today, and we would rather you learned that here than three weeks into an evaluation.

Where the data lives

The demo you are looking at holds invented records only.: Every company, person and record in it was made up for the purpose. No real record has ever been copied into it, for any reason, including our own testing.
A live system for a company holds that company's data and nothing else.: Not one database with a column saying which customer a row belongs to — a separate store, separately deployed. A shared database with a filter is one mistaken query away from showing one customer another customer's records, and that mistake cannot be undone by apologising.
The demo and the live system are kept separate from each other too.: A build running for a company holds its own store, and this demo holds another. They never touch, and nothing has ever crossed between them in either direction.

What the document check reads

It reads the documents sent with an application, and changes nothing in them.

Every file is read twice — once as a machine extracts it, once as the page renders — and the two readings are compared. Nothing is edited, nothing is written back, and no message is sent to a candidate or a client. Every finding goes to whoever is putting the candidate forward.

It holds the candidate's name, because an agency putting somebody forward needs it, and uses it to address them and nothing else. It holds no nationality, no photograph, no date of birth, no gender and no address — those fields cannot be sorted by if they do not exist, and a test walks the source tree and fails if one appears.

Who can reach it

One set of credentials per build.: No key exists that can read across two customers. That is a property of how they are deployed, not a rule someone remembers to follow.
No personal data in shared logging.: A shared log is a shared database by another name. Logs carry references — a candidate reference, a document id — never names, addresses or contact details.
This build accepts no uploads at all.: It runs on records already in the system. Where another build does take a file, it is read in memory, used, and not written to disk — but saying so here would imply this one takes them, and it does not.

What we do not do

We do not	Because
Train any model on your data	Your records are yours. Nothing you send is used to improve anything we sell to anyone else.
Send your data to a model provider unless the build needs one	Where a build uses a language model it is named on that build's page, and it only ever rephrases facts the code has already established.
Keep data after an engagement ends	The customer's data is deleted. Our own record of what we did — what was checked, when, and what it said — is kept for twelve months, because a report nobody can stand behind in a year is not evidence.
Move money, send messages, or take an irreversible action on our own	Every one of those ends at a person choosing it. This is the same rule in every build.

What is written down

A build running for a company keeps a record of what was checked, what the check said, and who decided what — with the version of the rules that applied at the time, so an old entry stays readable after the rules change. Entries cannot be edited or deleted. A record that can be tidied is one nobody can rely on, and the day it matters is the day somebody would most want to tidy it.

That record holds references, never personal details.

This demo keeps no such record. What you see on the page in front of you is all there is, and it is gone the moment you reload it.

What we would need before handling real records

A signed data agreement, before any access is given — not after. Where the data concerns people in the UK or the EU, that agreement has a cross-border section a lawyer has to complete, and it is the customer who is exposed without it, which is why their lawyer is the one who stops the deal. We do not accept access to a live system before it is signed.

Back to the demo · Plain text version of the demo page · Noorflows

Written 8 August 2026. If anything on this page stops being true, it is a defect and we would like to be told.