Technical ReadinessTechnical Readiness
Technical Readiness Certification: What to Look For
Technical Readiness

Technical Readiness Certification: What to Look For

Robert FosterWritten by Robert Foster

Every technical readiness certification rests on one gating condition: A defined scope exists, a limit is set around it, and a particular individual is accountable for the claims made about that scope. Until that condition is true, no information on a certificate, a level label or an assessment report provides data you can act on.

The reason is structural and stays true regardless of the tool you use. Certification is an act of attestation: An authorised individual confirms that evidence supports a fact regarding a specific subject over a defined period. Delete the limit so the topic becomes whatever the reader wants it to be. Removing the owner means no individual is responsible if the fact proves incorrect. Any result following that condition, whether it is a maturity level, a pre-audit diagnostic or a supplier's letter, inherits the weakness.

The rest of this page shows the work order and lists the main tools side by side so you can see what each one measures.

The procedure

1. Define the scope and assign a label to it.

Identify the system under review, the environment where it operates, and the individual accountable for its performance there. Then test the phrase. Give the project scope to an external reviewer for them to explain it. If they hesitate, the limit is not set. A readiness assessment carried out against an undefined subject produces a report that is true of no specific area, and everyone who later relies on it will interpret it as confirming their own version of the scope. Correct the text before you order any equipment.

2. Determine which type of insurance policy you are actually purchasing.

Three different items are described using similar terms. A level measures where a development has reached. A readiness certification confirms whether an organisation is prepared for external examination. An audit is that examination, conducted by the accredited body that issues the certificate. They are not interchangeable, and a supplier who offers you one while describing another has not settled the scope. The check before you move on: You can choose the kind of declaration in the document, and you know who is entitled to make it.

3. Define the evidence criteria before any evidence is collected.

Specify what serves as evidence, who may sign it, and what must appear on it. Evidence guidelines created after collection tend to be based on whatever was found, and the report ends up arguing for a conclusion the author had already reached. The check: You can link each finding in the final report to the criterion used for testing, which was established before the test started.

4. Evaluate the tool against the decision it informs.

A readiness tool is useful only if its output changes what you do next. Consider your choice regarding a funding release, a contract award or an approval to operate, and determine which result would change it. If every possible result leads to the same action, the assessment is ceremony. The check: you can say which result would stop you, and which would let you proceed.

5. Collect evidence from live work

Policies describe intent. Operations produce the trail that shows whether the intent is true. System logs, meeting minutes, access records and interview responses have time stamps and provenance; a policy document has only an author. The question that matters is whether the organisation can show the control working during an ordinary week. A control that operates only in the fortnight before the assessor visits will lapse again once the visit is over, and the evidence trail will show it. The check: Every piece of evidence traces back to a document produced in the course of the work.

6. Check the report for identified gaps, owners and measures.

Read for three things on every gap: An individual responsible for closing it, a deadline by which it will close, and a test that will show whether it has closed. A report that lists weaknesses without solutions shows your current state and provides no actionable tasks for your schedule. The check: You can give the report to the people listed in it, and each of them can explain their progress and when they will finish.

7. Perform the check again when the position changes.

Readiness is a state set at a particular time, based on the current configuration and environment, and it remains valid until one of those factors changes. A change of scope, a new environment, a merger or a change of supplier resets part of the picture. The check: you can say what would cause you to re-test, and who has standing to call for that re-test.

Each tool answers a specific question

Technology Readiness Level is a nine-step scale from basic principles observed through to a technology proven in operational service. The Aerospace Technology Institute says the meanings are subjective and the scale is imprecise, and uses them as a guideline for assessment. Its programme is designed to bridge the gap between proof of concept and demonstration in a representative environment. IDC, a product design consultancy, groups the scale into ideas and research at the low end, engineering, prototyping and refinement in the middle, and demonstration, production scale up and launch at the top. The tool assesses technology maturity and does not evaluate an organisation, a management system or a supply chain.

The European Union Aviation Safety Agency developed the Certification Readiness Level with the Clean Aviation Joint Undertaking within the CONCERTO project, as CompositesWorld reported. The Technical Readiness Certification consists of nine main steps and assesses how certifiable a concept of operation, business model, product or system is likely to be, alongside progressive engagement with the authority. Its stated purpose is to complement the maturity scale. Reach for it when the question is whether a novel design can be brought through certification at all, alongside the separate question of how far the engineering has travelled.

An ISO/IEC 27001 readiness assessment is a focused diagnostic against the management system requirements and the annex of controls, run before the certification body is engaged. CyberOne calls it a pre-audit exercise that finds non-conformities early and reduces the chance of failing a staged audit. Cornerstone Business Solutions draws the line that matters most here: the gap analysis identifies the work required, and the readiness assessment verifies that the work functions. The first produces a list. The second provides an assessment of operating reality.

Supplier-led readiness services show how far the label stretches. The Digital Marketplace entry for Node4 lists an evaluation of current practice, gap identification, recommendations and a roadmap, and states its own constraints openly: effectiveness depends on the buyer's present security position and its willingness to act, and compliance remains an ongoing process that outlives the assessment. Read the constraints section of any such listing before you read the benefits.

Government technology standards and guidance, published as a collection on GOV.UK, sets out the criteria used to design, build and buy technology across government, and links the standards, security classifications and procurement rules behind them. The Technical Readiness Certification has no readiness verdict, and for a public sector buyer it defines which declarations are admissible in the first place.

The mistake that survives every method

The mistake is treating the certificate as the object of the exercise. The certificate proves that evidence existed for a premise about a defined subject at a time. It provides no information about how the subject behaves in the environment where you will operate it, and it ceases to be valid once the subject or the environment changes. Teams that pursue the document tend to pass the audit and then meet the gap during an incident. Teams that pursue the answer keep the certificate as a by-product.

So the checklist for a certification, read as a buyer, is short and dull. Check who signed the certification, the subject it identifies, the period it covers, what the scope excludes, and what would cause the holder to re-test. A certificate that answers those five questions is worth the money you paid for the work behind it. One that answers none of them gives you a time and a logo, and the choice before you still stands where it stood.

Sources

Questions we get

What is the gating condition for certification?

There must be a defined subject with a clear boundary and a named person accountable for the claims made about it.

How should evidence be collected?

Evidence must come from live work, such as system logs and meeting minutes, rather than just policy documents.

What is the difference between TRL and CRL?

TRL measures the maturity of a technology. CRL assesses how certifiable a concept of operation or business model is.

When should a readiness check be re-run?

A re-test is needed when there is a change of scope, a new environment, a merger, or a change of supplier.

More from here

Technical Readiness In Project Management, Compared
Technical Readiness In Project Management, Compared
Technical Readiness For Digital Transformation
Technical Readiness For Digital Transformation
A Practical Guide to Technical Readiness Maturity
A Practical Guide to Technical Readiness Maturity