Regulatory Change Management

Track updates to compliance frameworks and regulations, assess the impact on your controls, plan the transition, and maintain a complete audit trail as your compliance landscape evolves.

What Is Regulatory Change Management?

Compliance is not a one-time event. Standards bodies publish new benchmark versions, regulatory agencies revise guidance, and legislatures amend laws — often on an annual or more frequent cycle. Each update can add new requirements, modify existing controls, retire outdated ones, or clarify ambiguous language in ways that change what you need to do.

Without a structured process to track these changes, organizations face two risks. The first is failing to adopt new requirements in time, leaving them non-compliant after an effective date passes. The second is over-reacting to changes and spending effort on requirements that do not actually apply to their environment.

TATER's Regulatory Change Management module gives you a single place to capture every change as it happens, evaluate which of your controls are affected, plan the work required to close gaps, and demonstrate to auditors that you have a mature, proactive process for staying current.

Navigating to Regulatory Changes

Open the application and expand the GRC section in the left sidebar. Click Regulatory Changes to open the module. The main view shows all tracked changes sorted by effective date, with the soonest upcoming deadlines at the top.

Creating a Change Entry

When you learn of a regulatory or framework update — from a vendor advisory, a mailing list, a standards body announcement, or an auditor's notice — create a change entry immediately. Capturing the change early gives your team more time to assess and remediate before the effective date.

Change Entry Fields

Click New Change to open the creation form. Complete the following fields:

Field	Description
Title	A concise, descriptive name for the change. Include the framework name and version or amendment number. Example: CIS Microsoft 365 Foundations Benchmark v3.1 Released or NIST SP 800-53 Rev 6 Draft Published.
Framework / Regulation	The affected standard. Common values: CIS M365, CIS Windows, CISA SCuBA, NIST 800-53, HIPAA, PCI DSS, SOC 2, ISO 27001, GDPR, CMMC. You can type a custom value for less common frameworks.
Change Type	New Requirement — A control or obligation that did not exist before Updated Requirement — An existing control whose threshold, scope, or implementation guidance has changed Retired Requirement — A control that has been removed and no longer needs to be met Clarification — Updated guidance that changes interpretation without adding or removing requirements
Summary	A plain-language description of what changed. Include enough detail for a reader unfamiliar with the framework to understand the nature of the change without needing to read the source document.
Effective Date	The date by which compliance with the new requirement is required. For draft publications, use the anticipated final date or leave it blank until confirmed.
Transition Period	The grace period some standards provide between publication and enforcement. For example, a standard published on January 1 with a six-month transition period would have an effective date of July 1.
Impact	High (significant new work required or controls fundamentally changed), Medium (moderate configuration or documentation changes), or Low (minor clarifications, minimal action needed).
Status	The current workflow stage (see the Workflow section below).
Assigned To	The person responsible for driving the transition to completion. Select from your People list.
Affected Controls	Control IDs in TATER that are impacted by this change. You can link existing controls from your catalog here.
New Requirements	For New Requirement or Updated Requirement changes: a list of the new control requirements or the updated control text. This documents what you need to achieve.
Retired Requirements	For Retired Requirement changes: the control IDs or descriptions being removed. Retired requirements can be used to justify removing scan controls that are no longer needed.
Gap Analysis	The difference between your current state and the new requirement. What configurations, processes, or policies need to change? This field drives the remediation plan.
Notes	Any additional context, links to the official announcement, auditor communications, or internal discussion relevant to the change.

The Change Management Workflow

Each change entry moves through a defined workflow. The Status field tracks where the change stands. Update it as work progresses so your team always has a current view of what needs attention.

Stage 1: Identified

The change has been discovered and logged. At this point you know a change is coming, but you have not yet determined what it means for your organization. The entry exists so nothing falls through the cracks.

During this stage, focus on getting the core facts right: framework, change type, effective date, and a clear summary. Assign an owner who will be responsible for driving the change to completion.

Stage 2: Impact Assessment

The assigned owner reads the source material and determines the practical impact on your environment. During this stage:

• Identify which existing TATER controls are directly affected by the change (link them in the Affected Controls field)
• Determine whether new controls need to be created in your catalog to represent the new requirements
• Classify the impact as High, Medium, or Low based on the scope of work required
• Complete the Gap Analysis field with a clear description of what needs to change
• For retired requirements, confirm that your organization can safely remove or stop tracking those controls

Stage 3: In Remediation

The gap analysis is complete and active work is underway to meet the new requirement. During this stage:

• Create remediation tasks or tickets for the specific configuration, policy, or process changes needed
• Link affected controls to Assignments to track which team members are working on which controls
• For new controls, add them to your catalog and ensure they are included in the next scan
• Update the Notes field with progress, blockers, and completion estimates

Stage 4: Compliant

All required changes have been implemented. Your most recent scan results show the affected controls passing, or you have documented evidence of compliance through manual review. Move the entry to Compliant once:

• A scan has run and the affected controls show a passing status, or manual evidence has been collected and reviewed
• Any new controls from the updated framework have been added to your catalog and scanned
• Retired controls have been removed from active monitoring or marked as no longer applicable
• The gap analysis documents the before and after state for audit reference

Stage 5: Closed

The change has been incorporated into your standard operating posture. It no longer requires active attention. Close an entry when:

• The effective date has passed and you have confirmed compliant status
• An auditor has reviewed and acknowledged the change and your response
• The entry has been superseded by a subsequent change to the same framework (in this case, close the older entry and update or create a new one for the superseding change)

Linking Affected Controls

The Affected Controls field on a change entry is one of the most important pieces of information for audit purposes. It creates a traceable link between a regulatory requirement and the specific technical controls in your environment.

Finding the Right Control IDs

TATER control IDs follow a consistent naming pattern. Cloud compliance controls use the format {PRODUCT}_{NNN}_{Description}, for example ENT_047_ConditionalAccess. SCUBA controls use {PRODUCT}_SCUBA{Section}_{Description}. You can look up control IDs from the Controls page or the Catalog page. Filter by the framework to quickly find the controls associated with a specific standard.

For a CIS benchmark update, the published change log will typically list the specific control numbers that have changed. Use those numbers to search the TATER catalog and find the matching control IDs.

Handling New Controls

When a framework update introduces an entirely new requirement with no existing control in TATER, you have two options:

• Create a catalog entry: Add the new control to your catalog with the new framework's control ID and description. Once it exists in the catalog, it can be linked to the change entry and included in scans.
• Document as a new requirement: Use the New Requirements text field to describe the new control and its implementation guidance. This is appropriate during the impact assessment stage before the catalog entry has been created.

Handling Retired Controls

When a framework retires a requirement, document the retired control IDs in the Retired Requirements field. This serves as justification if an auditor questions why a control that was previously tracked is no longer being scanned. You can also add a note to the control in your catalog explaining that it was retired by the framework update as of a specific date.

Using the Timeline View

The timeline view shows all change entries sorted chronologically by effective date. Entries with approaching deadlines are highlighted to draw attention. Use the timeline to answer questions like:

• What compliance deadlines are coming up in the next 90 days?
• Are there multiple changes from different frameworks that are due at roughly the same time, creating competing workloads?
• What changes are currently in remediation and at risk of missing their effective date?

The timeline is sorted in ascending order by effective date by default. You can switch to a list view sorted by status to see all open items grouped by workflow stage. Use the filter controls at the top to narrow by framework, impact level, or assigned owner.

Integrating With Your Audit Calendar

Regulatory change entries complement the Audit Management module. When an external audit is planned that covers a framework that has recently been updated, link the relevant change entries to the audit record so auditors can see the full lifecycle of how you responded to the update.

From the Audits module, open an audit engagement and navigate to the Related Items section. You can reference regulatory change entries as context for findings or as evidence of proactive compliance management.

Auditors conducting a review under an updated framework will often ask: "How did you become aware of this change? When did you assess its impact? When did you complete remediation?" A well-maintained change entry answers all three questions with timestamps.

Tips for Staying Ahead of Framework Updates

Reliable Sources for Framework Updates

Subscribe to official notification channels for the frameworks you must comply with:

• CIS Benchmarks: cisecurity.org/cis-benchmarks — CIS publishes new benchmark versions and interim notifications through their member portal and mailing lists.
• CISA SCuBA: cisa.gov/scuba — CISA releases baseline updates and technical reference documents through their website and US-CERT advisories.
• NIST: csrc.nist.gov — The Computer Security Resource Center publishes drafts and final publications with comment periods for major revisions.
• PCI SSC: pcisecuritystandards.org — The PCI Security Standards Council publishes DSS updates and supplemental guidance documents.
• HHS (HIPAA): hhs.gov/hipaa — HHS Office for Civil Rights publishes rule updates and enforcement guidance.

Triaging Changes Quickly

Not every framework update requires significant work. When a new change arrives, use these questions to quickly determine the appropriate level of response:

1. Does this framework apply to my organization? If it is a framework you do not use for compliance purposes, log it as Low impact and close it after the assessment.
2. How many controls are affected? A benchmark update affecting 3 controls out of 200 is lower priority than one that overhauls an entire section.
3. Are the affected controls currently passing? If you are already passing the affected controls, a tightened requirement may or may not push you out of compliance depending on the specific change.
4. What is the effective date? A change effective in 18 months can be scheduled into your normal work cadence. A change effective in 60 days needs immediate attention.

Using Change Templates

If your organization regularly tracks updates to the same set of frameworks — for example, CIS M365, CISA SCuBA, and NIST 800-53 — consider pre-populating a change entry template with the standard fields for each framework. When a new update comes in, duplicate the template entry and update the version-specific information. This saves time and ensures consistent documentation across all entries.

Reporting on Regulatory Changes

The regulatory change list can be filtered and exported to provide a status report for leadership or auditors. Common reporting scenarios include:

• Board / executive briefing: Filter for High-impact changes, show current status, and project completion dates vs. effective dates.
• Audit evidence package: Export all Closed and Compliant entries for a specific framework to demonstrate your change management process during an audit engagement.
• Quarterly review: Filter for all changes with an effective date in the next quarter to identify upcoming work that needs to be resourced.