Free resource
For development agencies and IT providers: the 18 checks an auditor and your clients' security teams test on an agency - client access, separation between clients, secure development, subcontractors and the incident terms in your contracts - plus a map from client clauses to your controls.
The actual structure of the file, straight from the template we use on live engagements.
Sheet: Start here
Read this tab first, then work through the checklist. Score honestly - a 'Partly' you can see is worth more than a 'Yes' you cannot evidence. This is a working tool, not a certificate: it shows where an assessor will push, before they do.
| Topic | Detail |
|---|---|
| What this is | An ISO 27001 self-check for software development agencies, outsourcing partners and IT service providers. It covers what an auditor and a client security team test on an agency in particular: access to client environments, separation between clients, secure development, subcontractors and the incident commitments in your contracts. |
| How to score | Yes = in place and you can show the evidence today. Partly = it exists but is incomplete, informal or unevidenced. No = not in place. Only a clear Yes counts when it is audited. |
| The #1 mistake | Scoping the ISMS around the office and the internal tools, and leaving out delivery. It certifies more easily, and it fails the first client security review, because client delivery is exactly what the client is asking about. |
| Second tab | 'Client clause map' takes the security clauses from your client contracts - including DORA and NIS2 supplier terms - and maps each one to the control and evidence that answers it. Answer once, reuse for every questionnaire. |
Sheet: Agency Checklist
Score each item Yes / Partly / No. The two middle columns are filled in for you: what a pass looks like for an agency, and the way agencies most often fail it.
| Area | Check item | What good looks like | Most common failure (the red flag) | Status (Yes / Partly / No) | Owner | Evidence / where it lives |
|---|---|---|---|---|---|---|
| Scope | The ISMS scope includes client delivery: teams, tools and access into client environments | The scope names the delivery services, the teams, your tooling and the client environments you work in | Scope limited to 'the office and internal IT' - easy to certify, useless in a client review | - | - | - |
| Scope | Every active client engagement is listed with what you access and hold | An engagement register: client, systems accessed, data held, people assigned, start and end | Nobody can say which engineers can reach which client's production today | - | - | - |
| Client access (5.15, 5.18) | Access to client systems is granted per engagement and approved | Access requested per person, per engagement, approved and recorded - ideally through the client's own identity provider | Shared client logins kept in a team password vault 'for convenience' | - | - | - |
| Client access (5.18) | Access to client systems is reviewed during and revoked at the end of each engagement | A dated review per engagement, and an offboarding step that removes access when the project or the person ends | Engineers still holding production access to a client the agency stopped working for last year | - | - | - |
Sheet: Client clause map
One row per security clause in a client contract or questionnaire. The example rows show the pattern - delete them and add your own. Where a clause comes from a regulated client (DORA, NIS2), check the exact wording in your contract: these rows paraphrase common terms, they do not quote the law.
| Client | Clause or question (paraphrased) | Usual source | Control that answers it | Evidence you can send | Gap / action |
|---|---|---|---|---|---|
| [Example bank] | Notify us of ICT incidents affecting our service and assist with our investigation | DORA client - ICT contract terms | Incident management process with per-client contacts (5.24-5.26) | Incident procedure, client contact list, last incident test record | - |
| [Example bank] | Grant us and our supervisor access, inspection and audit rights | DORA client - contracts supporting critical or important functions | Contractual commitment, plus an evidence pack kept ready | ISMS certificate scope, evidence pack, audit-right clause accepted | - |
| [Example bank] | Support an orderly exit and return of our data at the end of the contract | DORA client - exit arrangements | Engagement offboarding procedure: data return, deletion, access removal | Offboarding checklist from a completed engagement | - |
| [Example energy company] | Describe the security measures protecting our systems and data | NIS2 client - supply-chain security | Statement of Applicability and the controls behind it | SoA extract, policy summary, certificate | - |
Preview only. The download is a fully editable .xlsx file.
Go deeper
See how this template fits the wider readiness work, and where we pick it up on a live engagement.
Explore the related serviceMore resources