Roles and permissions

The following roles can update a framework:

Anyone with manager or contributor permissions for the program

Organizations need the latest, most accurate requirements for their program(s) to properly design controls and prepare for audits.

When compliance standards get updated—such as the transition from ISO/IEC 27001:2013 to ISO/IEC 27001:2022—making the shift can feel intimidating. Your existing controls might cover some of these new requirements, but in other cases, brand-new controls need to be designed and implemented.

Hyperproof’s Framework Update feature streamlines this transition. It automatically migrates your existing controls to the new version of the program, helping you understand and respond to the structural changes without risking your historical work.

How it Works

When a new framework version becomes available, an orange Update icon and an Update Available banner appear to the right of your program's name.

No Time Constraints: If you aren't ready to update, you can start whenever it works best for your organization. There is no time limit on the review process.
Work Preservation: Hyperproof copies your original program requirements, so your historical records remain untouched. Your existing controls link to the new program, leaving your control names, IDs, descriptions, tests, tasks, proof, and automations completely unmodified.
Dual Environments: After starting the update, you will temporarily manage two versions of your program—the old, out-of-date version and the new, up-to-date version. This lets you run your original program (e.g., ISO 27001:2013) while designing your new program (e.g., ISO 27001:2022) without duplicating daily tasks.

Steps to Successfully Update Your Program

The upgrade workflow follows four core steps:

Review the changes: Before initiating the update, review a summary outlining the changes to expect.
Create your new version: Generate the updated program version and give it a unique name. You retain full access to your original version until you choose to archive it.
Review new updates: Go to the Requirements tab in your new program to compare version changes, assign team tasks, adjust controls, and mark changes as reviewed.
Finalize your new version: Once all reviews are complete, finalize the update so the program operates normally.

Note: Some organizations may want to archive their original program at this time, while others might want to continue operating both versions until they have fully completed the transition.

Preparing for the Update

When a new version of your program is available, you’ll see an orange Update icon to the right of the program’s name on the card and an Update Available message on the program. If you aren’t ready to update, no need to worry—you can choose to begin at a time that works best for your organization. If you do not want to update right away, you can dismiss the banner; the icon remains visible.

Step One: Previewing the Changes

When you click the orange Update icon or the Update Available banner in your existing program, the Update preview window opens.

This window outlines structural differences between the frameworks, detailing:

Requirements without changes: Framework items that remain identical.
Updated requirements: Requirements with altered text.
Merged requirements: Multiple old requirements combined into a single new item.

If you are ready to proceed, click Get Started; otherwise, click Later to dismiss the banner while keeping the icon visible.

Step Two: Creating Your New Version

To keep your environments clear, you must provide a unique name for your new program version.

Locate the fields below Updated Program Name and enter your new program name.
Ensure the name is distinct from the original version so your team can easily differentiate between them.
Click Start Update.

What Hyperproof does behind the scenes:

Links your original controls to the relevant new requirements (controls will show links to both versions).
Retains all original control data, including control tests, tasks, and automations.
Imports users and their existing permissions.
Links proof directly to your new requirements (if that proof was previously attached directly to a requirement).
Copies historical activity streams and custom field values.

Note: Tasks and issues targeting requirements in the original version will not be copied into the new version.

Step Three: Reviewing Updates in Your New Version

Upon completion of the setup, you enter the Review Phase. Changes made to fields or links in your new version will not affect your live, original version, and vice versa. You can add or remove controls, manage custom fields, set permissions, and export files as usual.

Marking Changes as Reviewed

Any changed or removed requirements must be acknowledged by a member of your organization. Any user with access to the program can mark a change as reviewed, regardless of their role.

Note: Marking a change as Reviewed is an acknowledgment that the change has, in fact, been reviewed. Doing so does not trigger any type of change to your program.

Navigate to a changed requirement via the section tree or the arrows at the top of the screen.
Select the requirement and open the Update tab in the right panel to view historical text vs. new details.
Delegate work by creating tasks for your team or make changes to the requirement, such as:
Click Mark as Reviewed for each updated requirement to notify other team members that necessary updates have been made or assigned as tasks.

As items are reviewed, the total count on your section tree counter will decrement.

Understanding Types of Changes

In general, types of changes to requirements may include adding, updating, removing, merging, and splitting requirements. Here is how Hyperproof categorizes framework alterations to determine how data maps from the original framework to the updated framework:

Change Type	System Behavior	Required Action
No Changes	Automatically links controls, proof, custom fields, and activities.	No action required.
New Requirements	Added fresh to the framework.	Select the Controls tab to link existing controls, find suggested controls, or create new ones.
Updated Text	Maps existing controls, proof, custom fields, and history over automatically.	Review the new text and verify whether your controls need updates to meet the modified criteria.
Removed Requirements	Provides a summary of why the requirement was removed. Retains links inside your old program, but removes them from the new program once finalized. Program activity is no longer linked to these requirements.	Review the removal; you may need to manually relink those controls to an alternate active requirement. View your old program to see the old requirements and associated linked objects.
Merged Requirements	Resets custom fields/statuses to default. Automatically links previous controls and proof to the new combined target. Copies the activity feed to the new version.	Review custom fields and statuses and compare them to the original program requirements to determine if they apply in the new program. Review the expanded text to ensure your controls satisfy the full scope.
Split Requirements	Splits a single item into multiple criteria items.	Treated as one updated requirement combined with one or more entirely new requirements.

Step Four: Finalizing Your New Version

Once every changed or removed requirement has been acknowledged by marking them Reviewed, a Compliance Manager can conclude the transition phase.

Finalize the update by clicking the Complete Update button.
We recommend waiting to finalize until your team is fully comfortable with the structural differences.

Note: You can mark all requirements as Reviewed at any time by clicking the Mark all as reviewed button in the upper-right corner of the program, or work through them one at a time (recommended).

Managing Two Versions and Orphaned Controls

Dual Operation: You can keep both versions running concurrently if you have an upcoming audit scheduled under the old framework but want to build toward the new framework in the long term. While both versions are in operation,
controls are linked to both programs. Tasks will only target the program for which they were originally created.

Most organizations will likely want to archive their original program once their update is complete.
Orphaned Controls: After archiving your old program, some controls unique to that version might be left unlinked to any active program. You can find, archive, or relink them at any time via the main Controls tab. Use the Program filter on the Controls tab, and select No program links to list orphaned controls. Unlinked requirement proof remains searchable via the Proof tab.