Security & Trust: Protect Your Process Data

Process documentation lives uncomfortably close to the centre of a business. A diagram that shows how invoices are approved, how customers are onboarded, or how incidents are escalated is not neutral information. It reveals who holds authority, which systems touch sensitive data, and where the controls sit. The moment an AI tool starts helping a team draw those diagrams, it inherits a share of that sensitivity. Security is not a box to tick at the end of the procurement cycle; it is one of the first questions worth asking, and it deserves a clear, boring answer. This post walks through what to look for and what to ask when you are bringing any AI-assisted process modelling tool into sensitive work.

Why This Deserves Your Attention Early

Two things have shifted in the last few years. The first is that buyers are more sceptical of vague assurances than they used to be. A generic statement that 'your data is secure' no longer lands, partly because everyone says it and partly because the specific failure modes of AI-assisted tools are different from the ones traditional software had to defend against. The second is that the people best placed to evaluate the answers — security, compliance, and data protection teams — are often brought in late, after a product has already been chosen. That sequence makes renegotiation expensive and encourages teams to paper over concerns rather than solve them. The practical response is to put the security conversation at the front of the evaluation rather than the back, and to go into it with a list of questions rather than a list of hopes.

Access Control: Who Can See What

The first question to answer is who can see which diagrams and under what conditions. A mature platform lets you centralise identity through a single sign-on provider so that joiners, movers, and leavers inherit their access from the same source of truth your other systems use. It also offers role-based permissions that are specific enough to distinguish a viewer from a commenter, an editor, and an owner, with sensible defaults that make private the natural starting point rather than public. Sharing outside a narrow team should require an explicit role assignment rather than a generic 'anyone with the link'.

The reason to care about these details is that access control failures rarely announce themselves. They show up later, quietly, in the form of a diagram that ended up in the wrong team's folder or a contractor who still has access three months after the engagement ended. When you evaluate a tool, look for the shape of its access model rather than a list of features: how easy is it to keep permissions accurate as people move around the organisation, and how visible are the exceptions you have to approve?

Audit Trails and Change History

The audit story is about being able to answer a simple question six months from now: what changed, when, and who approved it? A good audit trail records views, edits, comments, and approvals against a timeline you can actually read. Versioning matters here too, not just so you can go back to an earlier diagram but so approvals can be tied to a specific, immutable state of the content. If an auditor asks whether the current diagram is the one that was signed off, the tool should be able to answer the question without human interpretation.

Retention is the other side of the same coin. Different workspaces have different needs — a finance team may have long retention requirements, a sales team may have shorter ones, and a compliance project may need a custom window. Ask whether retention can be set per workspace and whether historical states can be exported on demand when a review requires it. A retention policy you cannot point to, or cannot adjust per team, tends to become a quiet source of risk.

Sharing With Vendors and Partners

Most process work eventually reaches beyond the immediate team. Consultants review diagrams, auditors ask for evidence, and partners need to understand a handoff. Each of those moments is a small risk surface, and the handling matters. Look for sharing that carries a role rather than simply a link, so that the external reviewer cannot inadvertently edit something. Look for a clear record of what was shared, with whom, and for how long, so that periodic clean-ups are possible rather than imaginary. Ask whether sharing can be time-bound, and whether previously shared links can be revoked quickly if something changes.

A common failure pattern is the 'one link that got around'. Someone generates a quick share, pastes it into a chat, and over the following weeks the link quietly circulates to people the original author never intended. The mitigation is to make the short-lived, role-limited share the easy default and the permanent, open share the explicit exception.

Data Handling and AI Training

Because these tools are AI-assisted, two questions sit on top of the usual data protection ones. The first is how customer content is used. Is it used only to provide the immediate service to the customer, or is some portion of it used to train shared models? The answer matters, and a clear 'no, customer content is not used to train shared models' is the answer most enterprise buyers want. The second is how the underlying models handle confidential inputs: does a prompt describing a sensitive approval workflow stay inside a boundary you can reason about, or does it flow to a shared third-party endpoint? A tool that can answer both questions in plain language, without hedging, is easier to defend in front of a security review.

Alongside those AI-specific questions, the old-fashioned basics still apply. Encryption in transit and at rest, sensible key management, and a clear description of the third parties the service relies on. None of these are exotic, but they are the hygiene items that most thorough procurement questionnaires start with, so they are worth confirming up front rather than during the second round of legal review.

Questions Worth Bringing to the Conversation

Walking into a security review with a short, well-chosen set of questions tends to go faster than asking for a generic 'security overview'. Where is the data stored, and what region options are available? How is identity managed, and how are accounts provisioned and deprovisioned as people join and leave? What audit artefacts can the tool produce during a compliance review, and how quickly? How is customer content used — or explicitly not used — to train models? What is the sharing model when a diagram leaves the immediate team, and how easily can those shares be revoked? Six questions of that shape will typically get you further than any standard questionnaire, because they force specific answers about the way the tool actually works.

Practical Habits for Teams

Once a tool is in use, a small number of habits keep the posture healthy. Map roles to groups in your identity provider so that permissions scale with the organisation rather than being hand-edited each time someone moves. Set retention defaults per workspace and treat overrides as exceptions that need a reason written down. Keep approvals inside the tool so that the audit trail remains complete; approvals by email fragment the story and create gaps that take hours to reconstruct later. Periodically review external shares — a quick quarterly pass is usually enough — and expire anything that has outlived its original purpose. None of these habits are elaborate, but together they are the difference between a tool that stays trustworthy and one that quietly accumulates risk.

Security-First Adoption

The most effective adoption paths bring security and compliance in at the beginning rather than the end. Share a short overview of the tool's access model, audit capabilities, and data handling before the first pilot expands. Map what the tool offers against the control frameworks you already work inside, whether that is SOC 2, ISO 27001, or a sector-specific regime. Agree on an evaluation plan — what needs to be tested, what needs to be documented, and what would block a rollout — before the pilot finishes. That conversation is much shorter when it happens early, because there is still room to change direction. When it happens after the fact, the same discussion becomes a negotiation against sunk cost, which tends not to go well.

A Short Evaluation Step

The smallest experiment that tells you whether a tool will survive a serious security review is a thirty-minute walkthrough with your security lead. Show how single sign-on and permissions are configured, how the audit log reads for a realistic scenario, how retention is set, and how an external share would be created and revoked. If those four things feel clear and predictable, the heavier review will almost always follow the same pattern. If any of them feel improvised, it is better to know now than to find out during a procurement questionnaire two months later.

Where to Go Next

Security sits alongside two other themes that decide whether a process modelling tool earns its place in an enterprise. The first is compliance — whether the diagrams themselves pass review the first time rather than the third. The second is the economics of AI-assisted modelling — whether the time saved is real and visible enough to justify the investment. Together, those three themes — security, compliance, and economics — form the spine of a serious evaluation, and each of them deserves its own conversation.

If you are evaluating an AI-assisted process modelling tool and want to start the security conversation early, BPMN AI is happy to walk you through how access, audit, and sharing work in practice.