Neither rule defines material change precisely, so define it yourself and write it down. Good triggers include new internet-facing systems, major releases, infrastructure migrations, new vendors or integrations, mergers, and any change that alters what data a system holds or who can reach it. When in doubt, scan.
Where the phrase comes from
The FTC Safeguards Rule asks, absent effective continuous monitoring, for vulnerability assessments at least every six months and whenever there are material changes to operations or business arrangements, and whenever there are circumstances you know or have reason to know may have a material impact on the security program.
New York's financial services rule asks for automated scans, and manual review of systems not covered, at a frequency set by the risk assessment and promptly after any material system changes.
One speaks of operations and business arrangements, the other of system changes. Your trigger list should cover both. This is general information, not legal advice.
A starter list of triggers
| Category | Examples |
|---|---|
| System changes | New environment, major version release, framework upgrade, new public endpoint |
| Infrastructure | Cloud migration, new region, network redesign, new identity provider |
| Business arrangements | New vendor with data access, acquisition, new partner integration |
| Data changes | New data type collected, new storage location |
| Exposure changes | Service moved from internal to internet-facing |
| Threat information | Known exploited flaw in a product you run |
The last row matters. The FTC wording about circumstances you have reason to know may matter fits an exploited-flaw alert for software you run, even though nothing changed on your side.
Make the trigger operational
- Add a field to your change process: "Does this change meet the material change list?" Yes or no.
- If yes, the change record must link to a scan or assessment plan.
- For infrastructure as code, run scans in the pipeline on every merge, so most changes are covered automatically.
- For business events such as acquisitions, assign the security lead to the integration checklist.
- Subscribe to advisories for the products you run, with an owner.
What kind of scan
The response should fit the change. A new service needs a full scan and configuration review. A vendor integration needs a review of the integration code and credentials. A migration needs an inventory comparison to confirm nothing was missed, followed by a scan of the new environment.
Document the decisions
Keep a short log of material change decisions, including those judged not material, with a one line reason. This shows the process works, and it helps when an examiner asks why something was not rescanned.
Gaps between triggers
Triggers do not replace a regular cadence. Changes you did not know about, like a shadow service or a newly published flaw in an old component, are caught by scheduled and continuous scanning. Our post on how often must you scan covers cadence.
Where tooling helps
Safeguard's asset discovery helps find systems you did not list, and continuous monitoring flags newly disclosed vulnerabilities against components you already ship, covering the exploited-flaw trigger without waiting for a change.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring reacts to new information without any change on your side, the case scheduled triggers would miss.
Quick check
Is every release a material change?
Not necessarily. Pipeline scans cover routine releases. Reserve a deeper assessment for major releases and the other events on your list.
Who decides if a change is material?
Define it in policy: usually the change approver with the security lead, using your written list.
Sources
Last reviewed: 19 October 2026.
