What is the security lead's job in the model?
To verify, not to be told. The Digital FTE model on ftes.ai is built from mechanisms that can each be checked: isolation at the data layer, credentials encrypted with a separately held key and scoped per property, role-based permissions on every protected action, the approval gate, the always-escalate and never-automated lists, the audit trail, the wallet's hard stop, and the disconnect and deletion paths. The security lead's job is to check them, confirm the connection scopes at the tools, and keep the quarterly review.
The function's manager owns the role; you own the access and the evidence that the controls are what they say.
What should the security lead verify, and how?
Isolation: fetch two pages as a scriptless crawler to see what a crawler sees, and ask in writing how a request for another organization's record behaves; the right answer is that it returns nothing, not an error, and that background jobs carry the organization like user requests. Credentials: connect one tool with a dedicated token, confirm the secret is not visible in the workspace after entry, disconnect it, and confirm the disconnection appears in the audit trail with a name. Permissions: attempt a protected action with a member role and see it refused.
Gates: open a new role's Setup and confirm every class is at Level 0, read the always-escalate list, and read the fact-gate result on the first draft. Trail: trace one action end to end and export a sample. Spend: read the wallet and the hard-stop behaviour at zero. Provider: read the written answer on which provider, whether it trains on your data, and whether you can bring your own key.
- Isolation: scriptless fetch; cross-tenant read returns nothing
- Credentials: connect, confirm hidden, disconnect, confirm logged
- Permissions: forbidden action refused for a member role
- Gates, trail, spend, provider: each opened and read
What must the security lead confirm at the tools?
For every connection, that the account at the tool is dedicated to the role rather than a person's login, that its permissions are the narrowest the tool allows for the remit, and that a forbidden action, such as posting for a finance role or merging for a content role, is refused at the tool. Record each confirmation with your name and the date in the go-live checklist. The permission at the tool is the strongest control available, because it holds even if every other layer failed.
Where a tool cannot scope finely enough, note it; the remit restricts what the role reads and acts on within the connection, enforced by the approval gate, and the quarterly review revisits it.
What should the security lead refuse?
Refuse a person's login or a shared admin as a role's credential. Refuse a vendor that describes isolation in the interface rather than at the data layer, or that cannot name its model provider. Refuse a trail that cannot be exported. Refuse a governance model with a single trust setting instead of per-class autonomy, or with no never-automated list you can read. Refuse to sign off before the disconnect and deletion paths have been walked.
Refuse, too, to accept a certification in place of an answer; ask for both, and read the answer.
What does the exit look like, and why check it now?
The exit is: pause the role, disconnect every connection from the workspace, remove the dedicated accounts at the tools, revoke any connector links, export the audit trail, decide whether to retain the confirmed memory, request deletion through the privacy contact, and file the confirmation. Walk it now, on a test connection, so that on the day it matters nobody is searching for a credential. The offboarding checklist in the library is the list.
A path you have not walked is a path you cannot rely on.
How many hours does the security lead spend?
About three at go-live: one on the written questionnaire and the two verifications you perform yourself, one confirming scopes at the tools for the first role, one walking the exit on a test connection. About one per role per quarter afterwards: the connection review, asking of each whether it is still needed, still the narrowest scope, still dedicated, rotated on schedule, alongside the manager's governance audit. An incident, if one happens, is the four-step plan the manager runs with the trail; your part is the credential question, which the design has already answered.
That is less than most SaaS reviews cost, because the platform was built to be verified.
What does the platform not do for a security lead?
It does not claim certifications it does not hold, and it does not ask you to take its word for a mechanism; the security and GDPR pages describe what exists and the questionnaire answers say what is not claimed. It does not run inside your network. It does not grant itself credentials, widen a scope, or retain a connector link in a retrievable form. And it does not make the never-automated list configurable, by anyone, which is the property you would ask for if it were not already there.
A security lead who wants a badge should ask for it and then verify the mechanisms anyway. The mechanisms are what the review is.