You are losing marks on information security questions. Not because your systems are weak, but because your evidence is disorganised. When a public sector buyer asks how you protect their data, they do not want a 50-page policy document dumped in their lap. They want specific, signposted proof that your Information Security Management System (ISMS) works in practice, aligned to the contract they are awarding.
For UK SMBs bidding on frameworks like G-Cloud or Technology Services, or responding to local authority ITTs, ISO 27001 is often the price of entry. But holding the certificate is only step one. The difference between a passing score and a winning score is how you package and present the evidence behind that certificate. Scorers have hours, not days, to evaluate your bid. If they have to hunt for your Statement of Applicability or guess how your access controls apply to their specific project, they will score you down and move on.
This guide breaks down exactly what public sector evaluators look for in an ISO 27001 evidence pack. You will learn how to structure your documentation, which artefacts carry the most weight, and how to build a reusable repository that cuts your bid response time in half without sacrificing quality.
What this guide covers
- The baseline ISO 27001 requirements for UK public sector tenders.
- How to structure a compelling ISMS evidence pack for evaluators.
- Key mandatory documents you must include (and what to leave out).
- How to tailor your Statement of Applicability (SoA) for specific bids.
- A worked example of an information security tender response.
- Common mistakes bidders make when submitting security evidence.
- Frequently asked questions about ISO 27001 in procurement.
The baseline: ISO 27001 in UK procurement
In UK public sector procurement, information security is rarely just a tick-box exercise. Since the updates to the Procurement Policy Note (PPN) regarding cyber security and the increasing stringency of frameworks managed by the Crown Commercial Service (CCS), buyers demand robust proof of your security posture.
While Cyber Essentials Plus is often the mandated minimum baseline, ISO 27001 is the gold standard that larger contracts, especially in IT Services and Professional Services, expect to see. If your bid involves handling Official Data, hosting sensitive systems, or integrating with government networks, ISO 27001 certification from a UKAS-accredited (or IAF-recognised) body is frequently a mandatory pass/fail requirement.
But the requirement does not stop at uploading the certificate. Buyers use the tender process to assess how you apply the standard to their specific operational context. They want to see that your ISMS is not a dusty binder on a shelf, but a living system that actively mitigates the risks relevant to their contract.
The IAF accreditation trap
Before assembling your evidence pack, verify your certificate. A common reason for automatic disqualification at the Selection Questionnaire (SQ) or Pre-Qualification Questionnaire (PQQ) stage is submitting an unaccredited ISO 27001 certificate.
Public sector buyers require certification bodies to be accredited by the International Accreditation Forum (IAF). In the UK, this usually means the United Kingdom Accreditation Service (UKAS). If your certificate lacks the UKAS crown and tick (or an equivalent IAF member mark), evaluators will treat it as invalid. Do not waste time building an evidence pack around a certificate that fails the first compliance check.
Understanding the buyer's risk profile
Evaluators are not just checking for a certificate; they are assessing whether your ISMS aligns with their specific risk profile. A local authority procuring a waste management system has different security priorities than the NHS procuring a patient data platform.
Your evidence pack must reflect an understanding of the data you will handle. If the contract involves processing Personally Identifiable Information (PII), your evidence should heavily feature your data protection policies, encryption standards, and access controls. If the contract is for critical infrastructure support, the focus shifts to business continuity, disaster recovery, and availability metrics.
Structuring your ISMS evidence pack
When a tender asks for evidence of your information security arrangements, your response should be a curated, easy-to-navigate pack, not a data dump. Scorers are looking for clarity, relevance, and proof of implementation.
A strong evidence pack is modular. You build the core components once, keep them updated in your bid library, and tailor the executive summary and specific control references for each bid.
1. The Executive Summary (The "Why")
Start with a one-page summary that bridges the gap between your ISO 27001 certification and the buyer's specific requirements. Do not just say, "We are ISO 27001 certified." Say, "Our UKAS-accredited ISO 27001 ISMS covers the secure hosting and support of the proposed system, ensuring your Official Data is protected in transit and at rest."
This summary should explicitly name the systems, services, or locations that are in scope for the bid and confirm that they are covered by your ISO 27001 certification. It acts as a roadmap for the evaluator, telling them exactly what they will find in the rest of the pack and why it matters.
2. The Core Certification Evidence (The "What")
This is the foundational proof that your ISMS exists and is externally validated. Include:
- The Certificate: A clear, high-resolution copy of your valid, IAF-accredited ISO 27001 certificate. Ensure the expiry date is clearly visible and that the certificate is currently active.
- The Scope Statement: A concise document defining exactly which parts of your business, locations, and services are covered by the certification. This must align with the services you are proposing in the bid.
- The Statement of Applicability (SoA): The master list of which Annex A controls you have implemented and which you have excluded (and why). We will cover how to present this effectively later in the guide.
3. The Implementation Evidence (The "How")
This section separates the winners from the runners-up. It provides tangible proof that your policies translate into action. Rather than including every policy, select the artefacts most relevant to the contract's risk profile:
- Risk Assessment Methodology & Summary: Show how you identify and score risks. You do not need to share your entire internal risk register, but a redacted summary showing how you handle risks relevant to the buyer's data is powerful.
- Incident Response Plan: Buyers want to know what happens when things go wrong. Include your process for detecting, reporting, and resolving security incidents, highlighting your SLAs for notifying the buyer.
- Access Control Policy: Detail how you manage joiners, movers, and leavers, and how you enforce least-privilege access to the buyer's systems.
- Business Continuity & Disaster Recovery (BCDR) Summary: Provide evidence of your RTO (Recovery Time Objective) and RPO (Recovery Point Objective) capabilities, ideally backed by a recent test report.
4. Supply Chain Security (The "Who Else")
A major focus for government procurement, particularly following guidance from the National Cyber Security Centre (NCSC), is supply chain risk. Evaluators need to know that your security does not stop at your front door.
Include evidence of how you manage third-party risk:
- Supplier Security Policy: Your policy for assessing and onboarding new suppliers.
- Subcontractor Agreements: Redacted examples of clauses that mandate ISO 27001 compliance or equivalent security standards for your subcontractors.
- Audit Schedules: Proof that you actively monitor and audit your critical suppliers.
The critical role of the Statement of Applicability (SoA)
If the certificate is the headline, the Statement of Applicability (SoA) is the story. The SoA is arguably the most important document in your evidence pack because it maps the theoretical standard to your actual business practices.
When evaluators review your SoA, they are checking if your implemented controls align with their security requirements. If the tender specifies strict data encryption standards, the scorer will look at your SoA to confirm that control A.8.24 (Use of cryptography) is marked as applicable and implemented.
Tailoring the SoA for the bid
While your master SoA is a static document approved by your auditor, how you present it in a bid should be dynamic.
Do not force the evaluator to read a 93-row spreadsheet to find the three controls they care about. Create a "Bid-Specific Control Mapping" document. If the buyer's specification highlights remote access security and supply chain risk, extract those specific controls (e.g., A.6.7 Remote working, A.5.19 Information security in supplier relationships) from your SoA.
Present them in a table that shows:
- The Buyer's Requirement
- The relevant ISO 27001 Annex A Control
- How your organisation implements that control specifically for this contract.
This approach demonstrates that you have not just copy-pasted a standard document, but have actively considered how your ISMS applies to the buyer's unique needs.
Proving compliance: Artefacts over assertions
Evaluators are trained to spot hollow claims. Stating "We train our staff on cyber security" scores low. Providing the dates of your last three phishing simulations and the completion rate of your mandatory annual InfoSec training scores high.
When assembling your evidence pack, prioritize artefacts that demonstrate active management.
Examples of high-scoring artefacts
- Audit outcomes: A summary of your latest internal or external audit results, demonstrating continuous improvement. Do not hide minor non-conformities; showing how you identified and resolved them proves your ISMS is functioning correctly.
- Penetration test summaries: A redacted executive summary of a recent CREST-approved penetration test on the infrastructure you will use to deliver the contract.
- Training logs: Anonymised dashboards showing 100% compliance with mandatory data protection training for the team assigned to the project.
- Supplier agreements: Templates or redacted examples of how you enforce ISO 27001 requirements down your own supply chain (crucial for passing the risk down).
- Incident logs: A redacted log of a recent minor security incident, demonstrating how your team followed the incident response plan to contain and resolve the issue within SLAs.
Worked example
To illustrate how this comes together, here is a worked example of how to respond to a common tender question using your evidence pack.
Tender Question: Please detail your approach to ensuring the confidentiality, integrity, and availability of the Authority's data during the contract term. (Weighting: 15%)
Weak Response (Assertion-based):
We take data security very seriously. We are ISO 27001 certified and have strict policies in place to protect client data. All our staff undergo training, and our systems are protected by firewalls and encryption. We have a dedicated IT team that monitors our network 24/7. Please see our attached Information Security Policy.
Strong Response (Evidence-based):
We ensure the confidentiality, integrity, and availability (CIA) of the Authority’s data through our UKAS-accredited ISO 27001:2022 Information Security Management System (ISMS). Our certification (Certificate #12345, attached in Evidence Pack Section A) covers the secure hosting and delivery of the proposed platform.
Confidentiality: Access to the Authority's data is governed by our Role-Based Access Control (RBAC) policy (Control A.5.15). Only the five named engineers on this project will have access, enforced via Multi-Factor Authentication (MFA). All data at rest is encrypted using AES-256 (Control A.8.24).
Integrity: We maintain strict change management procedures (Control A.8.32). No changes to the production environment can be made without documented peer review and approval from our Information Security Lead.
Availability: Our infrastructure is designed for high availability. Our Business Continuity Plan (Control A.5.29) mandates daily immutable backups and a tested Recovery Time Objective (RTO) of 4 hours. A summary of our Q3 disaster recovery test, which achieved full restoration in 2.5 hours, is included in Evidence Pack Section C.
We have mapped our specific technical controls against your requirements in the attached 'Bid-Specific Control Mapping' document.
This strong response works because it directly answers the question using the CIA triad, references specific ISO 27001 controls, provides concrete technical details (AES-256, 4-hour RTO), and points the evaluator exactly to where they can find the supporting evidence.
Building a reusable bid library
Creating a tailored evidence pack for every single bid from scratch is inefficient. To scale your bidding efforts, you need a structured bid library.
A well-maintained bid library allows your bid writers to assemble 80% of the evidence pack in minutes, leaving them time to focus on the 20% that requires tailoring to the specific buyer.
What goes in the bid library?
- The Master Evidence Pack: The core documents (Certificate, Scope, SoA, key policies) in their most up-to-date, auditor-approved versions.
- Redacted Artefacts: A folder of pre-redacted examples (penetration tests, audit summaries, BCDR test reports) ready to be attached as evidence.
- Standard Responses: A database of strong, evidence-based answers to common security questions (like the CIA example above), tagged by topic (e.g., "Data Encryption," "Incident Response," "Staff Vetting").
- Control Mapping Templates: Blank templates for creating the Bid-Specific Control Mapping documents quickly.
Maintaining the library
A bid library is only as good as its latest update. Assign ownership of the security bid library to your Information Security Manager or CISO. They should be responsible for updating the master documents immediately following any internal or external audit, or whenever a policy is revised.
Bid writers should never be in a position where they are attaching an expired certificate or an outdated policy simply because they could not find the new one.
Common mistakes
Even experienced bid teams stumble when presenting technical security evidence. Avoid these common pitfalls:
- Mistake: Submitting the entire ISMS manual.
- Instead: Evaluators do not have time to read a 100-page policy manual to find one answer. Provide a clear executive summary, map your controls to their specific questions, and only attach the specific policies or artefacts requested.
- Mistake: Using an unaccredited certificate.
- Instead: Always ensure your ISO 27001 certificate is issued by a body accredited by UKAS or another IAF member. Unaccredited certificates are routinely rejected at the SQ/PQQ stage.
- Mistake: Failing to define the scope clearly.
- Instead: If your ISO 27001 scope only covers your head office, but the work is being delivered by a remote team or a subcontractor, you have a compliance gap. Explicitly state how your certification scope covers the services you are bidding to provide.
- Mistake: Relying on outdated evidence.
- Instead: Security is dynamic. Submitting a penetration test report from three years ago or a Business Continuity Plan that has not been reviewed since 2022 shows a stagnant ISMS. Always use the most recent, auditor-approved versions of your documents.
- Mistake: Ignoring the supply chain.
- Instead: Buyers are hyper-aware of supply chain risk. You must demonstrate how you enforce your security standards on your subcontractors. Reference your supplier security policy (Control A.5.19) and explain how you audit your downstream partners.
- Mistake: Using overly technical jargon without context.
- Instead: Remember that the person scoring your bid might be a procurement officer, not a CISO. Explain technical controls in terms of the business risk they mitigate. Instead of just saying "We use TLS 1.3," say "We use TLS 1.3 to ensure that all Authority data remains secure and unreadable if intercepted during transmission."
- Mistake: Treating security as an afterthought.
- Instead: Do not leave the security questions until the night before submission. Engage your technical and security teams early in the bid process to ensure the proposed solution aligns with your ISMS and that you have the evidence ready to back it up.
Frequently asked questions
Does ISO 27001 replace the need for Cyber Essentials Plus?
No. While ISO 27001 is a comprehensive management system, Cyber Essentials Plus is a prescriptive technical standard mandated by the UK government. Many central government contracts require both: Cyber Essentials Plus as a mandatory baseline, and ISO 27001 to demonstrate mature risk management.
Can we bid if we are "working towards" ISO 27001?
It depends on the framework and the buyer. Some buyers will accept a firm commitment and a project plan showing you will achieve certification before the contract start date. However, on strict frameworks (like certain CCS lots), lack of a current certificate at the time of bidding is an automatic fail.
Do we need to share our full Risk Register?
No. Your internal Risk Register contains sensitive operational details that should not be shared in a public tender. Instead, provide a redacted summary or a specific risk assessment focused solely on the delivery of the buyer's contract, demonstrating your methodology without exposing your vulnerabilities.
How often should we update our bid evidence pack?
Your core evidence pack should be reviewed quarterly, or immediately following your annual ISO 27001 surveillance audit. Always ensure you are using the latest version of your certificate, SoA, and policy documents.
What if our certification scope does not cover the entire proposed solution?
You must be transparent about this. If part of the solution falls outside your current scope, explain how you will apply equivalent security controls to those areas, or outline a clear timeline for extending your certification scope to cover them.
How do we handle subcontractors who are not ISO 27001 certified?
If a key subcontractor lacks certification, you must demonstrate how your own ISMS manages the risk they introduce. This might involve requiring them to complete a rigorous security questionnaire, conducting your own audits of their systems, or contractually binding them to specific security practices outlined in your policies.
