PBA Readiness Checklist
Principles-Based Assurance
Principles-Based Assurance (PBA) is an NCSC-aligned framework that evaluates whether your security controls are actually working in practice — not just documented in policy.
Unlike traditional compliance audits, PBA is evidence-led. Assessors don't want to see what you plan to do, or what your policies say — they want to see proof that your security processes are consistently applied, traceable, and operationally real.
This checklist covers the six key areas you need to have in place before undertaking a PBA-style assessment. Use it to identify gaps early and prioritise your preparation.
Governance
Good governance is the foundation of PBA readiness. Without clear ownership and oversight, even well-implemented security controls are difficult to evidence consistently.
Before assessment, you should be able to demonstrate:
Security ownership clearly defined across teams, assessors will want to know who is accountable for what, not just that a policy exists
Executive oversight of security maturity, boards and senior leadership should be able to speak to your security posture, not just delegate it
An active risk management process, documented, regularly reviewed, and visibly influencing decisions (not a static document)
Clear linkage between policy, risk, and operational controls, assessors look for a traceable thread from your risk register through to how controls are actually implemented on the ground
Common gap: Organisations often have governance documentation but cannot show that it reflects real operational decisions. If your risk register hasn't been updated in six months, that is a red flag.
Secure Development
PBA places significant weight on how security is built into your products and services not bolted on after the fact. This section often catches organisations out because the expectation is operational maturity, not just the existence of a secure coding policy.
You should be able to demonstrate:
Secure coding standards that are actively followed with evidence from real code reviews, not just a policy document referencing OWASP
A mandatory code review process peer review or tooling-assisted, with records showing it is consistently applied
Threat modelling integrated into development ideally at the design stage, with documented outputs linked to architecture decisions
Developer security training that is tracked and repeated not a one-off onboarding exercise; assessors want to see it is ongoing
Real-world evidence of secure development in practice pipeline logs, review records, SAST/DAST outputs, not retrospectively assembled documents
Common gap: Many organisations do some or all of these things but have not captured the outputs in a structured, retrievable way. If you cannot point to evidence from the last three months, you are not ready.
Operational Security
PBA assessors want to see that your security controls are functioning day today and not just that they are configured and forgotten. This section covers the operational layer between policy and evidence.
You should be able to demonstrate:
Monitoring and alerting capabilities that are active and reviewed, not just switched on; someone needs to be looking at outputs and acting on them
An incident response process that has been tested, tabletop exercises, post-incident reviews, or real incident records with documented responses
Access control policies that are enforced and auditable, who has access to what, how that is reviewed, and how joiners/movers/leavers are managed
Consistent application of processes across environments like development, staging, and production should not have wildly different security postures
Common gap: Incident response is frequently underprepared. Having a plan is not the same as having tested it. If you cannot point to a test or real incident in the last 12 months, revisit this before assessment.
Vulnerability Management
Vulnerability management is one of the most scrutinised areas in a PBA assessment because it directly reflects operational discipline. It is not enough to run scans — you need to show what you do with the results.
You should be able to demonstrate:
Defined remediation SLAs based on risk level, for example, critical vulnerabilities addressed within 24–72 hours, high within 14 days and evidence that these are being met
A centralised vulnerability tracking system which is not a spreadsheet; a structured tool that produces auditable records over time
Clear ownership of remediation with specific individuals or teams accountable for fixing identified issues, not a shared inbox
A penetration testing programme that repeats on a defined cadence (annual minimum), with findings tracked through to remediation
Formal risk acceptance procedures for vulnerabilities that cannot be immediately remediated, documented, approved, and time-limited
Common gap: Organisations often have scan results but no structured remediation tracking. Assessors want to see the full loop: vulnerability identified → prioritised → assigned → remediated → verified closed.
Evidence & Assurance
This is the section where most organisations fall short and not because their security is weak, but because they cannot demonstrate it clearly.
PBA requires evidence that is operational, not assembled for audit. The distinction matters: retrospectively created documentation is a significant red flag for assessors.
Your evidence should be:
Repeatable, generated consistently as part of normal operations, not produced on request
Traceable, clearly linked from policy through to process through to execution and output
Version controlled, showing that controls have been applied over time, not just at the point of assessment
Tamper-resistant or access-controlled because assessors need confidence that records have not been altered
The chain assessors are looking for is:
Policy → Process → Execution → Evidence → Outcome
If there is a break anywhere in that chain for example, you have a process documented but no evidence it is being followed then that gap will be identified.
Common gap: Evidence exists in multiple systems, owned by different teams, in inconsistent formats. Before assessment, conduct an internal evidence audit: for each control, ask "what is the artefact that proves this is happening, and can I retrieve it within 24 hours?"
Customer Assurance
PBA is ultimately about demonstrating your security posture to external parties, customers, procurement teams, regulators. This section ensures you can translate your internal controls into clear, credible external outputs.
You should be able to demonstrate:
The ability to respond to security questionnaires with evidence and not just yes/no answers, but referenced, retrievable proof
A clear articulation of your product security posture with a structured summary that a non-technical procurement lead can understand and act on
Documented controls and their implementation which is written in a way that supports due diligence without exposing sensitive internal detail
A useful test: if a major enterprise customer sent you a 50-question security questionnaire today, could you respond with evidence within five working days? If the answer is no, this area needs attention before assessment.
✅ Outcome
A PBA-ready organisation should be able to answer yes to three questions:
1. Can you show that your security controls are operating consistently and not just that they exist?
2. Can you produce structured, traceable evidence for each control area without retrospective preparation?
3. Can you explain your security posture clearly to a customer or assessor who will scrutinise it?
If the answer to any of these is uncertain, that is your starting point.
Not sure where your gaps are? SecurLab's free PBA Gap Assessment gives you a clear, expert-led view of your current position against NCSC PBA expectations — no commitment required.
Want to know exactly where you stand before starting a PBA assessment? Book a free PBA Gap Assessment— we'll work through these areas with you and give you a clear, prioritised action plan.