How to Review a Competency Framework Without Starting Again

Take a composite engineering firm I will call Kestrel. It has 240 people across two sites. Its competency framework was signed off in early 2023 after six months of workshops. It holds 38 competencies, four proficiency levels and around 900 recorded assessments. Three years on, the business has bought two CNC machining centres, merged its quality and compliance teams, and taken on design work for residential buildings. The framework describes a company that no longer quite exists.

The instinct at that point is to start again. Book the workshops, hire the consultant, write version two from a blank page. It is almost always the wrong call, because the expensive part of a framework is not the document. It is the 900 assessments, the development plans built on them and the shared language managers have learned to use. A rebuild throws all of that away.

To review a competency framework without starting again, treat it as a versioned standard rather than a one-off document. Set triggers for review (regulation, new roles, new equipment or technology, restructures), classify every proposed change as a wording fix, a re-level or a change to the standard itself, map each old competency to its replacement, and reassess only the people whose required standard has actually moved. Existing evidence stays attached to the version it was assessed against.

This guide walks Kestrel through that process, step by step, and covers the part most guidance skips: what happens to the evidence you already hold.

What does reviewing a competency framework actually involve?

A framework review is a structured check that each competency, behavioural indicator and proficiency level still describes the work people do and the standard the business needs. It ends in a new, numbered version, not a fresh document. Done well, it answers a short list of questions:

• Which competencies no longer match real work, and which roles have appeared that the framework does not cover?
• Has any regulation, standard or customer contract changed what "competent" means for a role?
• Are any competencies overlapping, so that managers rate the same behaviour twice under different names?
• Are the proficiency levels still pitched correctly, or has the expected level for a role moved?
• Which existing ratings remain valid after the change, and which people need to be reassessed?
• What else depends on the framework (job descriptions, interview guides, training plans, pay bands) and needs updating with it?

The last two questions are the ones that decide whether a review is cheap or ruinous. If you want a refresher on the building blocks first, our guides to proficiency levels and behavioural indicators cover the parts you will be editing.

When should a competency framework be reviewed?

Review it on a fixed cycle and whenever a trigger event happens, whichever comes first. A light annual check keeps it honest. A trigger, such as a change in law, new equipment or a new type of role, should start a targeted review straight away rather than waiting for the calendar.

There is no statutory review interval for a general competency framework, so be wary of anyone who quotes one. What the law does give you, in safety-critical work, is a list of events that should prompt one. Regulation 13 of the Management of Health and Safety at Work Regulations 1999 requires training when employees are "exposed to new or increased risks" because of a transfer or change of responsibilities, new or changed work equipment, new technology, or a new or changed system of work. It also says that training must "be repeated periodically where appropriate" and be adapted "to take account of any new or changed risks". Each of those events is also a reason to check whether the competencies behind the training still describe the job.

Professional frameworks run on their own cycles too. The SFIA Foundation says it typically operates a three-year update cycle, and SFIA 9 was published in October 2024. If your framework borrows from SFIA, as many digital and IT frameworks do (see our SFIA skills framework guide), its release schedule is a trigger in its own right.

Trigger	Example	Scope of review
Regulation or standard changes	A new statutory definition of competence for your sector	Every role the regulation touches
New equipment, technology or system of work	New CNC machining centres; a new ERP system	The technical competencies for affected roles
New or merged roles	Quality and compliance teams combined	Role profiles and required levels
Source framework updated	SFIA 8 to SFIA 9	Every competency drawn from that source
Assessment data looks wrong	Everyone rated at the top level on one competency	The indicators for that competency
Annual check	No trigger in twelve months	A light pass over the whole framework

At Kestrel, three triggers had fired without anyone starting a review: new machining equipment, a merged team, and new design work on residential buildings. That last one matters more than it looks.

When the legal definition of competence moves

Since 2023, the Building Regulations 2010 in England have carried a Part 2A on dutyholders and competence, inserted by SI 2023/911. Regulation 11F(1) says any individual carrying out building work or design work must have "the skills, knowledge, experience and behaviours necessary". The same Part lists "refusing to carry out work which is beyond their skills, knowledge or experience" among the necessary behaviours, and regulation 11I requires a person who ceases to meet the competence requirements to notify the person who asked them to do the work.

A framework written in 2022 as a list of technical skills has a visible gap against that wording: it says nothing about behaviours, and nothing about knowing the limits of your own competence. That is a targeted review, not a rebuild. You add or strengthen a small number of behavioural competencies for the affected roles and leave the rest alone.

What happens to existing assessments when the framework changes?

Existing assessments should stay attached to the version they were made against, and remain valid as a historical record. Only where a change raises or alters the required standard for a role do the people in that role need a fresh assessment. Everything else carries forward through a mapping from old competency to new.

Most update guides skip this step. Overwrite the old wording in place and every past rating appears to have been made against a standard nobody was assessed on. Start a new framework and every past rating is orphaned.

The competency platforms that handle this well all use the same pattern. Ausmed's documentation explains that an assessment already under way finishes "using the version they started with", anything started after an update uses the latest version, and historical records are never overwritten. Cornerstone's help pages describe review tasks that are locked to a specific competency model version. SFIA publishes a change tracker that identifies which skills were added, changed or retired, with an indication of whether each change may affect existing skills assessments.

You can run exactly the same discipline in a spreadsheet. The principle is simple: freeze, map, then reassess by exception.

Classify every change before you make it

Not every edit has the same consequence. Sort each proposed change into one of three classes, and give the framework a version number that tells people which class the release contains.

Change	Class	Existing ratings	Reassess?
Reword an indicator, same meaning	Wording	Carry forward unchanged	No
Rename a competency	Wording	Carry forward under the new name	No
Merge two overlapping competencies	Structural	Carry forward the lower of the two ratings, or review	Only where ratings disagree
Split one competency into two	Structural	Copy to both, flagged as provisional	At the next routine assessment
Retire a competency	Structural	Keep as history, stop collecting	No
Raise the required level for a role	Standard	Stay valid; the gap is new	Only people now below the bar
Add a new competency	Standard	None exist	Yes, risk-ranked
Change what a level means	Standard	Treat as unverified	Yes, for everyone rated at that level

The merge rule is a judgement call. Decide it once, write it into the release note, and apply it consistently.

How do you review and update a competency framework?

Run the review as a short project with a named owner, a change log and a defined end point. Seven steps cover it.

1. Name an owner and a small review group. One person owns the framework. HR, two or three function leads and someone close to day-to-day assessment make the decisions. Large workshops produce wish lists.
2. Collect evidence of drift. Pull the triggers that have fired, manager feedback, and assessment data. A competency where nearly everyone sits at the top level, or where nobody is ever rated, is telling you something.
3. Log each proposed change. One line per change: what, why, which roles, and its class (wording, structural or standard). Anything without a reason is rejected.
4. Map old to new. For every competency in the current version, record whether it is unchanged, renamed, merged, split, re-levelled or retired, and where its ratings go.
5. Decide who reassesses, and when. Only standard changes trigger reassessment. Rank it by risk: safety-critical and regulated competencies first, the rest at the next routine check-in.
6. Publish a new version with a release note. Number it, date it, and freeze the old version. The note lists what changed, who is affected and what they need to do.
7. Update everything downstream. Job descriptions, interview guides, training plans, development plans and any pay or grading links that reference the old wording.

Step 5 is where the time goes, so it is worth being precise. Our guide to competency assessment methods covers how to choose between observation, professional discussion and evidence review for the people who do need reassessing.

Kestrel's review, worked through

Here is how the composite Kestrel review played out. The numbers are illustrative, not benchmarks, but the shape is typical.

The review group logged 23 proposed changes. Seven were rejected as preferences with no reason attached. Of the 16 that survived:

• Nine wording changes. Indicators rewritten in plainer English, two competencies renamed. No reassessment.
• Four structural changes. "Quality awareness" and "Compliance awareness" merged into one competency after the teams combined. One competency split. Two retired, because the manual process they described had gone.
• Three standard changes. A new CNC programming competency for 18 machinists, a raised required level on "Inspection and measurement" for 9 quality technicians, and a new behavioural competency on working within the limits of your competence for the 14 people doing design work on residential buildings.

Two additions, two retirements, a merge and a split cancel out, so the framework still held 38 competencies. It moved from version 2.0 to version 3.0. The first number changed because the standard changed for some roles; a release of wording fixes alone would have been 2.1.

The reassessment list was the payoff. Instead of reassessing 240 people against a new framework, Kestrel reassessed 41 people, some on more than one competency. The design team went first because of the regulatory exposure. Of the 900 historical assessments, none were deleted. The two retired competencies stayed visible as history, and the merged competency carried forward the lower of each person's two prior ratings, with a note telling managers to confirm it at the next one-to-one.

Where framework reviews go wrong

Silent edits

Someone fixes a typo, someone else tightens an indicator, and a year later nobody can say which version a rating was made against. Every change, however small, goes through the log and lands in a numbered release.

Changing the framework mid-cycle

Publishing a new version while appraisals or assessments are open means half the organisation is rated against one standard and half against another. Publish between cycles, or let in-flight assessments finish on the version they started with.

Reassessing everybody

It feels thorough. In practice it buries managers, delays the people who genuinely need checking, and teaches staff that a framework change means a test. Reassess by exception.

Forgetting what hangs off the framework

Kestrel's interview guide for machinists still referenced a competency that had been retired. If the framework changes and the hiring, training and grading documents do not, people are recruited and paid against a standard you no longer use.

Where StaffCircle fits

All of this works on paper, but it is easier when framework, role profiles and assessments live in one place.

Regenerate roles rather than rewrite them

StaffCircle's AI-assisted competency framework generates role profiles, skills and required competency levels from your own company information, with editable prompts. When a role changes, you update the inputs and review what comes back, instead of rewriting every profile by hand.

See the new gaps straight away

When a required level rises or a competency is added, the people now below the bar are the reassessment list. Skills gap views and single-person dependencies make that list visible, which is the information step 5 depends on. Our skills gap analysis guide explains how to read it.

Turn reassessment into development

A new gap should not just be a test date. Personalised development plans and regular check-ins let managers close it as part of normal one-to-ones, which is how Kestrel handled the provisional ratings on its merged competency.

Final thoughts

A competency framework is never finished, and that is fine. What you need is a way to change it that does not cost you the evidence you have built up. Set your triggers, classify every change, map old to new, and reassess only where the standard has moved. Your next review then becomes a few weeks' work instead of a six-month rebuild.

If you would like to see how StaffCircle keeps frameworks, role profiles and assessments connected, book a demo.

FAQ

How often should a competency framework be reviewed?

Run a light review once a year and a targeted review whenever a trigger fires, such as a change in regulation, new equipment or technology, a restructure or new roles. There is no statutory interval for a general competency framework, so the right rhythm is the one that keeps it matching real work without moving the goalposts every quarter.

Who should be involved in a competency framework review?

Give the framework one named owner, usually in HR or L&D, and a small review group: two or three function leads and someone close to day-to-day assessment. Gather manager and employee feedback as evidence, but keep decisions with the small group. Large workshops tend to produce long wish lists rather than a short, justified change log.

Do you need to reassess all staff when a competency framework changes?

No. Reassess only the people whose required standard has actually moved: those affected by a new competency, a raised required level or a change in what a level means. Wording changes and renamed competencies carry existing ratings forward. Rank the reassessments by risk, starting with safety-critical and regulated competencies.

What happens to old assessments when the framework is updated?

They should stay attached to the version of the framework they were made against and remain part of the historical record. Map each old competency to its replacement so ratings carry forward where the meaning is unchanged. Do not overwrite the old wording in place, or past ratings will appear to have been made against a standard nobody was assessed on.

How do you version control a competency framework?

Give each release a number and a date, freeze the previous version, and keep a change log listing every change, its reason, the roles affected and its class. A simple convention is to bump the first number for changes to the standard and the second for wording fixes. Publish a short release note with each version.

Should you rebuild a competency framework or update it?

Update it in almost every case. A rebuild discards the assessments, development plans and shared language you have already built. Rebuilding only makes sense when the existing framework was never used, or when the organisation has changed so completely that almost no competency maps to a current role.

How do you retire a competency from a framework?

Stop collecting new ratings against it from the next version, but keep existing ratings visible as history. Record in the change log why it was retired and whether any of its content moved into another competency. Then remove it from job descriptions, interview guides and training plans so nothing downstream still refers to it.

What should you do when two competencies overlap?

Merge them into one competency with a single set of indicators, and decide a rule for existing ratings before you publish. A cautious rule is to carry forward the lower of the two ratings and ask managers to confirm it at the next one-to-one. Write the rule into the release note so it is applied consistently.

How long does a competency framework review take?

A targeted review against a single trigger can be done in a few weeks if the framework already has an owner and a change log. A first review of a framework that has drifted for several years takes longer, because you need to rebuild the mapping between old and new versions. Reassessment then runs on its own risk-based schedule.

What needs updating after a competency framework changes?

Anything that quotes or references it: job descriptions, role profiles, interview guides and scorecards, training and development plans, onboarding checklists and any pay or grading criteria. List these in the release note so each owner knows what to change, and check them before the new version goes live.

---