Which Controls Were Relaxed Before the Audit?

Showing that a control operates also means showing how long it has been switched on. A rule enabled two weeks before the audit date produces no evidence for a review covering a full year. This article is about why the history of your settings has to be recorded.

The Question an Auditor Should Ask

An experienced auditor sees on screen that the rules are switched on and notes it. The next question is whether they were switched on for the whole period.

The question does not assume bad faith. Controls are relaxed for legitimate reasons too: a rule produces false positives, an approval step creates a bottleneck during a busy period, a threshold is unrealistic. The problem is not the relaxation but its going unrecorded.

When it goes unrecorded both sides lose. The organisation cannot show the reason for the relaxation, and a well intentioned decision looks arbitrary. The auditor cannot be satisfied that the control operated throughout, and has to raise a finding.

Why a Settings Change Stays Invisible

In most systems a settings change is either not recorded at all or thrown into the same bag as every other change. The second is marginally better than the first but yields the same outcome in practice: finding the critical one in a thousand row list of settings changes requires knowing what you are looking for.

An auditor cannot be expected to know. The people who know which setting is critical in an organisation are that organisation's own team. So the responsibility for marking the critical ones belongs to the system itself.

The second reason for invisibility is a record that does not carry the old value. A line saying a setting was changed, without saying from what to what, is just a timestamp. What an audit needs is the old and the new value recorded together.

Weakening a Control Is Its Own Event

The fix is simple and its effect is large: the settings capable of weakening a control are identified in advance, and changing one of them is recorded under its own name rather than as an ordinary settings update.

That turns "which controls were relaxed before the audit" into a question a single query can answer. An empty answer is evidence. A non empty answer is also evidence: decisions that can be shown with their reasons and explained.

Where that list of critical settings lives matters too. If it sits in a database table, someone can first remove an entry from the list and then switch the protection off unapproved. So the list belongs in code: changing it requires a release, and a release is a record in its own right.

Four Eyes: The Person Changing and the Person Approving

Recording alone is not enough. If one person can switch a control off, do their work and switch it back on, the record only shows up after the fact and has no preventive effect.

The right structure is this: a settings change that could weaken a control is not written to the live record immediately. It waits as a pending entry for a second authorised person to approve. On approval it is applied, and both names enter the record.

Two points need care here. First, approving your own request must always be forbidden; otherwise four eyes becomes a one person formality. Second, the approval right should be the screen's own right: someone without permission to change a server setting should not be able to approve a change to it either.

A rejected settings change should be recorded too, and the rejected entry should show the values that were requested. What demonstrates a control operates is not the changes that passed but the ones that did not.

Why Past Requests Are Not Affected

If a rule changed today, which rule was a request from six months ago judged against? This comes up often in audits and most systems have no answer.

For there to be an answer, the rule set has to be frozen onto the request. When a request is saved, the rules and effective settings that shaped it are stored in a single audit event. No later change touches that record.

This protects both sides. The organisation is protected from yesterday's decision being judged by today's stricter rule. The auditor can check whether yesterday's decision actually matched yesterday's rule, instead of guessing from today's screen.

Freezing has one limit and it should be stated: only requests raised after the date it started carry this information. For older requests the field is empty. The file does not invent missing information, it states that it is missing.

A Pre Audit Checklist

Answer these five questions inside your own organisation before the audit. Every one you cannot answer is a question the auditor will ask.

• Which control settings changed during the period, and who changed them?
• Does every change have a written reason?
• Was each change approved by a second person, or made by one?
• Was a switched off control turned back on, and if so when?
• Was any settings change rejected during the period?

The last one is the most useful. A list of settings changes with no rejections in it means either that no bad proposal was ever made or that approval is a formality. The way to tell which is to look at the rejection records.

Frequently Asked Questions

Does four eyes apply to every setting?

No, and it should not. Putting every setting behind an approval turns approval into a formality; someone giving thirty approvals a day reads none of them. The rule should be limited to settings capable of weakening a control. Which ones those are should be decided in advance, and the list should live somewhere it cannot be casually extended.

What if we need to switch a control off quickly in an emergency?

You can, but it should still take two people. An emergency shortens the approval step, it does not remove it. Having the approver write the reason afterwards, with that entry staying on an open list, lets you move fast and still account for it later. Opening a path where one person can switch a control off removes that control entirely.

Do passwords appear in settings change records?

They should not. Password style secret fields are masked in the payload written to the audit record; when a settings change is tracked, the secret that changed is not written into the trail. This is the basic rule that keeps the audit records themselves from becoming a leak channel, and it matters all the more because evidence packages can leave the organisation.

How do we show an auditor that the rule set was frozen?

The evidence file for the request carries the rule set in force that day as its own section, and the file is sealed. The auditor can see both the rule and that the file has not changed since it was produced. Showing today's screen is not a substitute; the screen shows today, the file shows that day.