A Security Tooling Checklist for Multi-Client IT Consultancies

A client roster spanning old .NET applications, a modern React frontend, and a client-managed WordPress site will not get equal coverage from either tool. Snyk supports a wide language list and works regardless of which platform hosts the code, which suits a consultancy with a genuinely mixed portfolio. GitHub Advanced Security only helps on repos that live on GitHub, so if half your clients host on GitLab, Bitbucket, or an on-premises server, plan for a second tool or accept a coverage gap and say so plainly in your engagement notes.

When each client engagement runs its own scanning setup, findings live in a dozen different places and nobody at the consultancy has a clear view of overall exposure. Build one internal dashboard, even a simple one, that pulls a status summary from every active client's scanner. Without it, a critical finding on a smaller client can sit unnoticed for months simply because nobody was assigned to check that particular queue.

A simple weekly summary, even a shared spreadsheet someone updates by hand, beats no summary at all while a proper dashboard gets built.

Some clients will decline to pay for a scanning tool or refuse to enable one on their existing GitHub org. That refusal doesn't remove your exposure if you're still responsible for maintaining the code. Document the recommendation in writing, note the client's decision, and revisit it at each contract renewal. A written record protects the consultancy if a vulnerability the client declined to address later causes a breach.

Revisiting it annually also gives the client a natural, low-pressure opening to reverse an earlier decision once budget or priorities shift.

Consultants collect access over years of client relationships: repo access, cloud console access, admin panels. Every credential that outlives its engagement is a standing risk that has nothing to do with which scanner you chose. Review access quarterly across all active and recently closed engagements, and revoke anything tied to a project that's wrapped up.

A quarterly access review should check:

• Repository access held for each client, compared against the engagements that are still active on your roster.
• Cloud console access, so accounts from finished projects are closed rather than left standing.
• Admin panels and other client-side logins that consultants collected over years of relationships.
• Who on your team holds each credential, so the review ends with a named owner for anything you keep.

Without a written SLA, a critical finding can sit open for months while nobody is quite sure whose job it is to fix it. Federal agencies work to roughly a two-week deadline for known exploited vulnerabilities once a CVE is listed¹; adapting a similar window into your own client agreements gives both sides a concrete standard to point to instead of an argument about what 'urgent' means.

Put the timeline in the statement of work itself, not just in an internal runbook, so the client has the same reference point the consultancy is using. A timeline that only exists on your side of the relationship still leaves room for a disagreement about what was actually promised once a finding turns up mid-engagement.

A consultancy's staffing on a given account changes more often than a client's own engineering team does, and each staffing change is a chance for institutional knowledge about a client's security setup to quietly disappear. When a consultant rolls off an account, require a short handoff note covering what scanning is enabled, what's currently open, and what the client agreed to for a remediation timeline, addressed to whoever picks up the account next.

Without that habit, a new consultant often starts from zero on a client they've inherited, re-discovering the same findings a departed colleague already knew about and may have even started fixing. That's wasted billable time at best, and at worst it's a finding that quietly falls through the gap between two people who each assumed the other had it covered.