eProcureAI / Platform / Security
Security and trustProcurement data shows exactly what your company buys, from whom, at what price and who approved it. We treat it accordingly.
Bring your reviewer to the demo. We would rather answer early than at contract stage.
Spend data is a map of how a company operates. What it buys, from whom, at what price, who signs it off and where the thresholds sit.
That combination is genuinely sensitive. It reveals commercial terms your suppliers would rather competitors did not see, internal authority structures, and where the approval gaps are for anyone looking to exploit them.
So the security posture here is not a compliance checkbox exercise. Encryption throughout, access granted by department rather than accumulated per person, and an audit trail nobody can quietly edit after the fact.
The most common failure in a software evaluation is security review happening at contract stage, when everybody has already decided and any finding becomes an argument rather than a question.
We would rather your reviewer joined the demo and asked the hard questions while there is still time for the answer to matter.
With keys managed centrally and rotated. Customer data does not leave the environments we control.
Redundancy across availability zones, with restore procedures that are tested rather than documented and assumed.
Permissions belong to departments and are inherited, with administrative roles kept separate from transactional ones.
Every approval, amendment, override, signature and export recorded with the actor, the timestamp and the stated reason. Records cannot be edited afterwards.
Regular penetration testing by third parties plus continuous vulnerability scanning, with findings tracked to closure.
Access granted to a department and inherited by its members, rather than copied from another user and accumulating over years.
Authentication uses your existing identity provider, so there is no parallel password estate and your leaver process continues to apply.
Records are append only. That is the difference between a log, which describes what a system thinks happened, and evidence, which somebody can rely on.
Most of this is available under NDA during evaluation. Ask on the call rather than at contract stage.
| Area | What we provide | When |
|---|---|---|
| Architecture | Overview and data flow diagrams | Under NDA during evaluation |
| Sub processors | Current list and what each one touches | Under NDA during evaluation |
| Third party testing | Current attestations and summary findings | Under NDA during evaluation |
| Access and identity | Role definitions, provisioning and de-provisioning flows | On request |
| Resilience | Backup cadence, tested restore procedures, incident response | On request |
| Data handling | Retention, deletion, export formats | On request |
If your reviewer needs something not listed here, ask. We would rather find out during evaluation than during contracting.
We process it to provide the service. Ownership does not transfer at any point.
Not with partners, not in aggregate, not as market data.
Your spend, contracts and supplier terms are not used to train models serving anybody else.
In standard formats, not as a favour and not as a retention tactic.
Honoured under the terms in your agreement rather than negotiated at the time.
The sub processor list is available under NDA rather than being something you have to ask twice for.
The split matters because a shared responsibility model only works if both halves are stated plainly.
Your identity provider, your access model, and who can do what inside your organisation.
Everything underneath, including the parts you would otherwise have to run yourselves.
We would rather answer the hard questions early than discover them at contract stage.
Book your free demoRelated: Access and Permissions