Published September 11, 2026 · 7 min read
Here is a test worth running on any outsourcing vendor, including us. Ask them this: "If one of your team leaders ran a query directly against your database instead of using your application, what would they get back?"
A surprising number of answers amount to "they wouldn't do that." That isn't a security control. It's an assumption about behaviour — and it is the single most common gap between a vendor that looks secure in a questionnaire and one that actually is.
What "screen-deep" security looks like
In a lot of systems, permissions live in the interface. The application decides what to show you: a team leader's dashboard queries only their own team, an agent's page loads only their own records. The screen behaves correctly, so the demo goes well and the security questionnaire gets ticked.
The problem is that the screen is not the only way in. Underneath it, the database often holds one big table that any authenticated part of the system can read in full. The restriction exists in the code that draws the page — not in the data itself. So the protection holds exactly as long as every query in the system, forever, including every future feature and every rushed hotfix, remembers to apply it.
That's a lot of weight to put on everyone remembering.
The question underneath: where is the rule enforced?
The stronger pattern is to push the restriction down into the database itself, so it applies no matter what does the asking. Three controls matter most, and all three are things you can ask about directly:
1. Row-level security on every record
Rather than the application filtering rows, the database refuses to return them. A policy attached to the table itself says an agent sees their own records, a team leader sees their line, an HR admin sees the company. Run a direct query and you get back exactly what the screen would have given you — because the boundary is in the same place for both.
This is what makes multi-tenant work safe when a vendor runs several clients on one platform. Your data isn't hidden from other clients by a filter somebody has to remember to write. It's unreachable.
Ask: "Is access enforced at the database level or in the application layer? Can you show me what a direct query returns?"
2. Least privilege by default
The default state of a new table should be no one can touch it, with access granted deliberately afterwards — not the reverse. It sounds like a small distinction and it is the whole game, because the failure modes run in opposite directions. Start closed and a mistake means a feature breaks loudly in testing. Start open and a mistake means data is exposed quietly in production, possibly for years.
Writes that carry real consequences — a payroll adjustment, a quality score, a policy acknowledgement — should go through audited functions rather than open table access, so the rules around a change cannot be bypassed by writing to the table directly.
Ask: "What are the default permissions on a newly created table? Who has to approve widening them?"
3. An audit trail nobody can forge
Most systems log who did what. Fewer can tell you where that "who" came from. If the application tells the database "this action was performed by user 4471," then anything able to talk to the database can claim to be user 4471 — and your audit trail becomes a record of what the system was told, not what happened.
The identity written against a logged action should be read from the authenticated session itself, never accepted as an input from the caller. That single design decision is the difference between an audit log you can hand to a regulator and one you can only hand to a colleague who already trusts you.
Ask: "Where does the actor identity on an audit record come from — the session, or the request?"
Why this matters more in regulated work
For collections, lending, mortgage servicing and healthcare support, the record is the product. When a consumer disputes how an account was handled, or a regulator asks who authorised a decision, you are not being asked whether your vendor had good intentions. You are being asked to produce a defensible record of what happened and who did it.
An audit trail is only defensible if it could not have been written by anyone other than the person it names. Everything above is what makes that sentence true — and it's why we'd rather be asked these questions than the usual ones. (Our broader posture, certifications and roadmap are on the compliance page; the FDCPA-specific checklist is in this article.)
Your pre-signing checklist
- ☐ Is access enforced in the database, or only in the application?
- ☐ What does a direct query return for a restricted user?
- ☐ Do new tables start with permissions revoked?
- ☐ Do consequential writes go through audited functions?
- ☐ Is the actor on an audit record read from the session, not supplied by the caller?
- ☐ Can every decision — leave, correction, warning, audit, coaching — be traced to a named person?
- ☐ Is client data isolated from other clients at the data layer, not the screen?
None of these require you to be technical to ask. They do require the vendor to be specific in answering — and how quickly they can be specific tells you most of what you need to know.
Ask us these questions
Every record in our platforms is protected in the database itself, not by a screen that hides a button — and the identity on every logged action is read from the session, so it can't be supplied by the caller. We'd rather walk you through the evidence than send a brochure.
