Large Number of Controls Auto-Retiring

[Erik Nelson]

Hello all,

I've been trying to research a reported issue of a large number of Controls being automatically retired by "System", but I'm coming up empty. I'm not seeing a consistent link across nor am I finding a Business Rule, Scheduled Job, or Scheduled Flow that would impact them. I guess the pertinent information is:

1) We do have UCF integration enabled, but I've been told this is just a one-time import and not something that runs on a schedule.

2) The Controls are largely assigned to Active Entities that haven't been swapped between active and inactive.

3) Not all Controls are being retired, both from an association to Entity standpoint as well as association to Control Objective.

4) All Control Objectives are also active.

Anyone have any thoughts or spots they suggest checking? The last time we saw something was on 07/10 and was Controls associated with 19 different Control Objectives with thousands of controls being retired per.

Thank you,

Erik

[wojasso]

When controls unexpectedly change to **Retired** the first thing to do is confirm that the update is coming from a scheduled script rather than a user. Open one of the affected control records and use **History → List** to inspect the audit entry that changed the **state** field; the audit context will show the scheduled job or business rule that executed as `system`.

From an IRM perspective there are a few out‑of‑box mechanisms that can automatically retire controls:

* **Lifecycle rules tied to Entities or Control Objectives** – A business rule and helper script (`sn_compliance.ControlLifecycleHelper`) retire controls when a related *Entity* or *Control Objective* is set to *Retired* or *Inactive*, or the relationship is removed. If someone de‑scoped an entity or objective, the downstream controls will be set to Retired by this rule.
* **UCF content updates** – With the UCF integration enabled there is a scheduled import processor that updates controls. If the property to automatically retire removed controls is on, any control that disappears from the source or is superseded will be retired during the import. Check the **UCF Content Update** scheduled job and the property `sn_ucf.retire_removed_controls`.
* **Scheduled jobs / flows** – Jobs such as *Retire Controls on Objective Retirement* and flows triggered by entity retirement call `ControlLifecycleHelper.retireControls()`. Go to **System Definition → Scheduled Jobs** and filter by application *Policy and Compliance* with names containing `control` or `retire` to see if any are running.

Suggested approach:

1. Pick a control that was retired on 07/10 and open its **History** to see exactly which update set entry retired it (the *sys_update_name* often includes the scheduled job name).
2. Cross‑check the status of the associated **Entities**, **Control Objectives** and **Policies** to make sure none were inactivated or removed on that date.
3. If UCF is in use, review the UCF import logs for that run and the integration properties to see if automatic retirement is enabled.
4. Review any custom scheduled scripts or flows in your environment that call the control lifecycle helper.

Once you know which process is doing the retirement you can either disable the offending job, adjust the lifecycle rule, or modify the UCF settings. Without auditing the specific record update it’s very hard to tell whether the cause is UCF, entity de‑scoping or a custom job.

[Erik Nelson]

Hi wojasso,

Where in audit context are you seeing the job/action being taken by System? I've looked at the history of the records, as indicated in my original post but don't see anywhere it says anything to indicate what triggered the update (if I had, I wouldn't need to post! LOL 😁)

Before posting, I did check for scheduled jobs/flows and we don't have any. I also checked  Entities/Control Objectives/Policies and they weren't flip-flopped on active state.

It looks like UCF setup doesn't have any additional properties or schedules and runs only when we go into the setup and run an import. I checked for the property you mentioned and it does not exist in our instance. The Team that owns the UCF side said that the items aren't being retired on their side (which is backed up by the fact that it's not retiring *all* the Controls).  I'm not seeing any data in the import tables for UCF at this point. What would I specifically be looking for in the logs to see something that may have come from there?

Thanks again!