The four things it genuinely needs
Systems that touch a lead. CRM, every inbound channel, calendar, ticketing, and anything else an enquiry passes through. The object is to trace every path a lead can take and find where each one stops, which requires seeing the paths rather than a summary of them.
Twelve months of existing history. Whatever the systems already hold. Nobody should be asked to assemble a data pack: the raw system is both less work and more trustworthy than a hand-prepared export, and if something is not in a system it is not evidence anyway.
One owner with authority. A person who can grant access and answer questions without escalating. This is the single most common reason an engagement stalls, and it is a requirement rather than a preference.
Thirty minutes each from four to six people, across sales, operations and service. No preparation. These conversations exist to find the gap between what the system records and what people actually do — which is the one thing no amount of system access reveals, and which never becomes a figure on its own.
What it should never be given
- Financial systems. Nothing in a leakage diagnostic requires reading your general ledger. Deal values and conversion rates come from the CRM.
- HR or employee records. Never relevant.
- Blanket document or drive access. A frequent and lazy request — "give us the shared drive so we can find things". This is how an engagement ends up with visibility of an internal memo it had no business reading.
- Payment or card data. Out of scope entirely.
- Write access to anything destructive. No ability to delete records, modify pricing, or alter historical data. Read-only wherever the platform supports it.
- Production credentials belonging to a named individual. A service account per integration, always, so that revoking it later is a non-event rather than a password reset for a person.
The pattern across all six is worth noticing: the narrow request is also the better-engineered one. A firm that knows exactly which permissions it needs has scoped the work; a firm that asks for administrator access has not, and will be reasoning about your business from a pile of data it did not need.
The six questions to ask before granting anything
These are the questions a buyer’s IT or legal function will raise, and it is faster to put them to the firm directly at the point of commissioning than to discover the answers during provisioning.
- 01Is there an NDA, is it mutual, and who signs it?
- 02Is access read-only wherever the system supports it?
- 03Who inside the firm sees the data, and is it limited to the engagement team?
- 04What happens to the credentials at readout — revoked by you, or returned?
- 05Is anything retained afterwards, and if so what, where, and for how long?
- 06Are subcontractors or offshore staff involved at any point?
Why the real transaction is access, not the fee
A $5,000 diagnostic is not really a $5,000 decision. It is a decision to hand a firm you have not worked with visibility of the system your revenue runs through, and an operating partner at a $40M company will not clear that internally on the strength of good copy about the report. The fee is the small half of the transaction.
Which means the security conversation is not a procurement formality to be got through — it is a substantial part of what you are evaluating. A firm with crisp answers has done this often enough to have been asked before. A firm that treats the question as friction is telling you something about the last several engagements.
Data residency, and the questions that follow from it
For Canadian companies, and particularly for anyone with public-sector or healthcare-adjacent customers, where data physically sits is a real constraint rather than a formality. Ask where data is processed, where it is stored at rest, which sub-processors are involved, and what the retention period is. Four questions, and a firm that cannot answer them in writing has answered them.
Ask separately whether anything from your systems is used to train models. The answer should be no by default and it should be contractual rather than a statement of intent on a marketing page.
How to scope access properly, whoever you hire
- One service account per integration, never a shared human login.
- Least privilege, then verify it. Grant the narrowest permission set and confirm the firm cannot reach something it should not. Assumption is not verification.
- Field-level scoping where the platform supports it. A leakage diagnostic needs enquiry source, timestamps, owner, stage and value. It does not need free-text notes on every customer.
- Separate read and write paths. Read from systems of record; write nothing, or write to a defined and logged set of fields.
- Log every access, and check the log once during the engagement rather than never.
- Diarise the revocation for readout day. The most common security failure in consulting engagements is not a breach — it is a credential that stayed live for three years.
None of this is onerous and all of it is faster to do at the start than to retrofit. It also has a useful side effect: a firm that works comfortably inside a tightly scoped account is demonstrating, before it produces any finding, that it understands the difference between the data it needs and the data it would like.