Security reviews die in the RFP grid
Every platform vendor answers "yes" to every row of a security questionnaire. Role-based access? Yes. Audit trail? Yes. The grid cannot distinguish a permission model designed in from one bolted on, because the difference only shows up in the follow-up question — and in whether the vendor can demonstrate the answer live instead of describing it.
This checklist is built around those follow-ups. For each item you get the opening question, the second question that exposes a weak answer, and — as a concrete reference point — how xMatix answers it. The checklist is meant to be useful whatever platform you are reviewing: put every vendor through the same nine questions, in a live demo, on a realistic user.
The nine questions
1. How granular is the permission model — does it reach individual fields?
The question: Can you restrict what a user can do — read, create, update — per entity, and per field within an entity?
The follow-up that exposes weak answers: "Show me a user who can open a record but cannot see one field on it — then show me that the same field is also hidden from that user in the API response and in exports." Field security that only lives in the UI is not field security; it is field decoration.
xMatix's answer: Permissions in xMatix are granted through profiles, which carry both entity-level operations and field-level permissions. Profiles answer what a user may do; a separate access layer (next item) answers which records they may do it to. The two decisions are distinct and both must pass.
2. How is record-level access decided — and can it vary per entity?
The question: Beyond "can this user read invoices at all," how does the platform decide which invoices? Ownership? Hierarchy? Teams? And can the policy differ between, say, leads and payroll records?
The follow-up: "Is the access model additive, subtractive, or both — and can you state the precedence rules?" A vendor who cannot state precedence in one breath has a model their own support team argues about. Also ask whether record access is one global switch or configured per entity — real organizations need open collaboration on some entities and strict need-to-know on others.
xMatix's answer: Each entity carries its own record-access policy. Visibility resolves through a defined set of grants: record ownership, role-hierarchy roll-up, team membership, direct shares, business-unit-targeted shares, and internal or external default access. All grants are additive — a deliberately simple model with no hidden deny rules to untangle — and the resolution order is documented, not folklore.
3. Can the platform explain why a user sees a record?
The question: When someone asks "why can this user see this record?" — a common audit and incident question — can an admin get the answer from the platform, or must they reverse-engineer it from configuration?
The follow-up: "Show me, live, the exact grant that gives this user access to this record." Platforms without this diagnostic turn every access question into a half-day investigation.
xMatix's answer: xMatix ships an access-explanation diagnostic: for a given user and record, it walks the decision — profile, role hierarchy, team, business unit, record policy, sharing — and shows which grant produced the verdict. It is exactly the kind of feature to demand a live demonstration of.
4. What does the audit trail actually cover?
The question: Which changes are audited — data records only, or also configuration, permission changes, and code?
The follow-up: "Show me the audit entry for a permission change and for a script change, not just for a record edit." Data-only audit trails miss the changes attackers and insiders care about most: the ones that alter who can see what.
xMatix's answer: xMatix maintains a full audit trail on records, with an audit browser in the product. Tenant-authored automation scripts are versioned and audited, and AI tool calls and approvals are audited as well (item 9). Ask any vendor to enumerate what is not audited — the honest answer is more informative than the feature list.
5. How is tenant isolation enforced — policy or architecture?
The question: What technically prevents one customer's queries from touching another customer's rows?
The follow-up: "Is isolation enforced at the data layer, or does it rely on every application query remembering to filter?" A filter convention is one forgotten clause away from a cross-tenant leak; you want guards that sit below the application code. Also ask how development, sandbox, and production are separated from each other.
xMatix's answer: xMatix is multi-tenant with tenant-isolation guards enforced at the data layer, on top of sharded databases, and runs development, sandbox, and production as isolated environments with separate subscription boundaries. Release artifacts are built once and the same immutable image is promoted through environments — what was tested is what runs.
6. How are external users kept apart from internal ones?
The question: When dealers, vendors, or customers get logins, are they a bolt-on portal with its own rules — or the same security model with a different scope?
The follow-up: "Show me the default access an external user gets on an entity, next to the internal default, and show me an external user's view of a record an internal colleague also sees." Separate portal codebases are where access-control assumptions quietly diverge.
xMatix's answer: xMatix distinguishes internal and external audiences inside one security model: each carries its own default access per entity, and audience is one of the inputs to the same record-access resolution every user goes through. External users are a scoping of the model, not an exception to it.
7. What happens to deleted data?
The question: Is deletion immediate and permanent, or recoverable — and who controls retention?
The follow-up: "Who can restore a deleted record, is the deletion itself audited, and what happens when the retention window ends?" Accidental and malicious deletion look identical until the investigation; without a recovery window, both are permanent.
xMatix's answer: xMatix has a recycle bin with retention: deleted records are held and restorable within the configured window rather than destroyed on click.
8. How do changes reach production — and how do they come back out?
The question: Can configuration be built and tested in a sandbox and promoted to production as a reviewed unit — and if the change goes wrong, what does rollback actually restore?
The follow-up: Two, both revealing. "When you create a sandbox, is production data masked, and are integrations deactivated automatically — or does your test environment email real customers?" And: "Is rollback a re-deploy of the old version, or does it restore the actual prior state?" Also ask what happens if production changed while the change set was in review.
xMatix's answer: xMatix supports one-click sandbox tenants — cloned metadata, optionally masked data, integrations auto-deactivated — and change sets that move sandbox to production through a draft, build, review, and apply flow. Undo replays before-images captured at apply time, restoring what actually was rather than what a script assumes, and drift detection flags when production has moved underneath a pending change.
9. What can the AI see, and under whose identity does it act?
The question: Now that every platform embeds an assistant: when the AI answers a user, whose permissions govern the answer? And when it writes data, who approved that?
The follow-up: "Ask the assistant, as a restricted user, a question whose answer includes records that user cannot see — and show me the result." Then: "Show me the audit trail of an AI-initiated write, and show me the spending controls." An assistant with a privileged service account is a permission-bypass with a chat interface; an assistant without budgets is an unbounded invoice.
xMatix's answer: Sense, the xMatix AI, executes under the calling user's identity — every answer respects that user's row- and field-level permissions, with no privileged backdoor. Writes go through a single governed update action that is capability- and approval-gated, and all tool calls and approvals are audited. Consumption is governed too: licensed seats, credit allocations, and per-tenant and per-user quotas enforced before the model call. The admin-facing copilot follows the same rule — it acts with the admin's own permissions, previews changes first, and requires explicit approval for destructive actions.
Running the review
- Demand demonstrations, not descriptions. Every item above ends in something a vendor can show live in under five minutes. If they schedule a follow-up instead, note it.
- Bring a restricted test user. Most demos run as a super-admin, which proves nothing. Ask the vendor to build a deliberately limited user in front of you, then run items 1, 3, and 9 as that user.
- Write down the "no" answers. No platform answers all nine perfectly, and a vendor who admits a gap crisply is usually a better bet than one who answers everything with "yes, via configuration." The goal is not a perfect scorecard — it is knowing exactly where your compensating controls need to live.