Security

What we want to be honest about

We display no certification logos that we do not have. Agentancy is not currently ISO 27001-certified and has no SOC 2 report. What we do have is a fully worked-out ISO 27001 file — policy, risk register, an assessment of all 93 controls from Annex A, and an incident register — which we maintain internally and review periodically.

If you are considering working with us and would like to see that file: just ask. We share it under a confidentiality agreement, including the points that are still open. We consider a supplier who can show where they stand more trustworthy than a supplier with a logo and nothing to back it up.

Where your data is held

• Hosting in the Netherlands. The application, background processing and database run in Amsterdam.
• Document storage in the EU. Invoices and receipts are held in European object storage.
• Document AI via a European route. Recognition runs through a fixed EU region. Where an AI route processes outside the EU, that is stated explicitly in our privacy statement with the corresponding safeguards.
• Your data does not train AI models. Not ours, and not those of our suppliers. That is laid down contractually and is switched off in the settings of every route we use.

Encryption

• In transit: all traffic to and from Agentancy runs over TLS. HTTP is redirected to HTTPS and our domains are on the browsers' HSTS preload list, so a browser never tries it unencrypted.
• At rest: database volumes are encrypted. The connection details of your accounting package, access tokens and two-factor secrets are also encrypted separately with AES-256-GCM, so that they stay unreadable even for someone with access to the database.
• Key management: encryption keys are held only in the platform's secret store, never in the source code. An automated scan on every change blocks a secret from being added to the repository by accident.

Access

• Denied by default. Permissions are role-based; anyone without rights to an administration does not see it — this is checked again on every route and is enforced at database level as well, as a second layer.
• Two-factor authentication is available for all accounts, with recovery codes that are stored encrypted.
• Repeated failed login attempts temporarily block an account: after ten failed attempts within fifteen minutes any further attempt is refused, after which the block lapses automatically. The counter runs per account across all our servers, so changing IP addresses cannot get around it.
• Audit log. Actions that matter are recorded in a log that can only grow, never be altered. That applies to our own administrative actions too.
• Administrative access to production is limited to those who need it, runs solely over an encrypted connection, and the database is not reachable from the public internet.

Submitted documents

Documents that arrive from outside — by upload, through the client portal or by email — are checked on their actual content: we do not trust the file type the sender states. Documents you fetch yourself from your accounting package through a connection do not go through that content check; after all, they were already put into that package by you or your client. Submitted files are never executed, and the viewer in the application is sandboxed so that a document cannot run code in your session.

To avoid any misunderstanding: this is a check on the file type, not a virus scanner. We do not run a malware scan on submitted documents.

For the email channel you can set per administration which sender domains are trusted. If that list is filled in, mail from any other domain is rejected and the document therefore does not come in — bear that in mind when you add a new supplier. If you do not fill in a list, all mail comes in but an unknown sender is flagged, and such documents never post automatically: they always wait for a human.

Availability and recovery

• Daily encrypted snapshots of the database.
• A documented recovery plan with agreed targets for how much data may be lost at most and how quickly we are running again, with a recovery procedure that has actually been carried out and not merely written down.
• Health checks on the application and the background processing, which restart automatically on failure, plus email alerts to the administrator.
• Honest about the limit of this: that alerting runs through our own system. If the mail chain itself fails, the alert never arrives — that happened to us once and is recorded in our incident register. An independent, external monitor that closes this gap is on the list and is not connected yet.

Secure development

• Every change goes through a pull request. Four checks must be green — secret scan, type check, tests and a full end-to-end test run — before anything can go to production. Pushing directly to the main branch is technically impossible, even for the owner.
• Every pull request is automatically offered to a second, independent review track. That is a safety net alongside the mandatory checks above, not a hard gate: if a review does not arrive, or it concerns an emergency fix, the change can be merged without one, deliberately and visibly.
• Dependencies are scanned for known vulnerabilities on every change and weekly on a fixed schedule, with remediation deadlines set by severity.
• We do not use production data to develop or test.

If something goes wrong

We have a documented incident process with triage within four hours, a recovery playbook and a register in which every incident gets a file — including the assessment of whether notification was required and why or why not.

In the event of a personal data breach we inform you as the controller without undue delay and no later than the deadline set in our data processing agreement, with everything you need to make your own notification to the Dutch Data Protection Authority within 72 hours.

Found a vulnerability?

Report it at info@newgenerationleads.com. We respond to every serious report, take no legal action against researchers who stick to the usual ground rules, and keep you informed until it is resolved. One request: no automated scans on production and no access to other people's data.

Documents

• Data processing agreement — including our obligations in the event of a data breach and on termination.
• Privacy statement — with the full, current list of sub-processors, their purpose and their region.
• Terms and conditions

We announce changes to sub-processors 30 days in advance by email to firm owners, with a right of objection within that period.

A questionnaire to fill in?

Many firms have to assess their own suppliers, certainly now that the supply chain obligations from the Dutch Cybersecurity Act reach through to software suppliers. Send your questionnaire to info@newgenerationleads.com — we fill it in, and we answer the questions where the answer is “not yet” as well.