Attestation Frequency - on Control but not Control Objective

[Mathew Hillyard]

Hi everyone,

I am aware that you can set periodic attestation of Controls using the "Attestation frequency" field on a Control. Whilst this gives complete control (excuse the pun) over how often a content owner has to attest for a given Control, it kind of goes against the "as high-level as you can" automation across IRM.

Is there a particular reason why SN has not configured the application to optionally set the Attestation frequency at the Control Objective level? This can still be overridden at the Control (or Entity) level, but where you have a Control Objective with lots of Controls were you require all or the majority to be re-attested with a certain frequency, it seems odd to have to then go set that on each Control individually.

Thanks

Mat

[JadaP]

Mat, I’ve run into this same thing and had to sit with it for a minute before it clicked.

The Control Objective is purely a template, it doesn’t carry operational responsibility, which is why attestation frequency lives at the Control level and not above it. The Control Objective defines the what, not the when.

For example, a Control Objective that says “reset admin credentials every 60 days” tells you what the control requires, it says nothing about how often you should be checking that it’s actually in place. That’s an operational decision. A low-risk entity outside SOX scope might only need that control assessed quarterly, while a high-risk entity where you need strong assurance might warrant daily continuous monitoring so you can respond fast when a failure surfaces. Same Control Objective, completely different monitoring cadences, and that variation belongs at the Control level.

For the bulk scenario you’re describing, whoever on the entity owner’s team is responsible for a control, sitting on thousands of controls that all share the same frequency, the OOB list action is actually your friend here. Filter your Controls list by entity, select all, and mass-update the Frequency field in one shot. Not glamorous, but it works and it’s fully OOB.

Where it gets more manual is when controls under the same objective have different cadences, and honestly, that’s intentional. The platform not inheriting frequency automatically is kind of a forcing function for accountability. Each person responsible for a control should be making a conscious decision about the appropriate cadence for their specific scope and risk context. The entity owner ultimately needs to make sure their team has their controls articulated correctly, frequency included.

[Mathew Hillyard]

I hear you, but the fact that you may have a use for it at the higher level means it really should be there. It's the same gap in my mind as not having a proper platform way to manage key controls - the only OOTB method being the "Key Control" field, which again is on the Control and not the Control Objective and to my knowledge is only visualised via the SOX Content Pack on the SOX Dashboard.

I'm also not sure I agree that you automatically need to assess different entities with different frequencies. If it's related to intrusion prevention, then bad actors have been known to use access to something innocuous to wreak havoc, so I'd look more closely at what the Control Objective is intended to mitigate. Where it may become relevant is for a subset of critical systems where your regulatory requirements are tough, or where an entity (e.g. a Business Application) is rapidly changing. It would make sense to have both options (or actually three, because you can set Attestation frequency on an Entity too).

The beauty of IRM is that it allows management at a higher level - rollup of compliance from Control all the way to Policy or Authority Document, automated management of Entities and automatic creation and management of Controls. It would be very easy to have it at the parent level, even it is more of an edge case. 

Changing more than one page of records in the list view is slow and using "Change all" is a fine way to lock the user session until it times out after 5 minutes 😉

However, the entire attestation piece isn't testing a Control, it's the content owner claiming that they're fulfilling their responsibilities, so I guess it's a moot point as to the real world value of periodic attestation anyway.