Is Your Installation Audit Ready?

An organisation's controls live in two places: in the procedure document and on the system's settings screen. Audit looks at the first, real life runs on the second. When the two drift apart nobody notices, because nothing compares them. This article is about what a control that makes that comparison regularly should look like.

Written Down Versus Switched On

The procedure says "the person who approves cannot execute the change themselves". There is a parameter in the system that enforces this, and that parameter is switched off. Both statements are true; they simply do not know about each other.

This does not happen out of bad intent. The typical story is this: the parameter arrives switched off at installation because the team has not defined its roles yet. A few weeks later the roles settle, but nobody goes back to the parameter. A year passes. The auditor reads the procedure, then asks for a sample request and sees that the approver and the executor are the same person.

The finding that surfaces at that moment is not "there is no segregation of duties". It is worse: there is a written claim that the control exists, and the claim is not true. In an auditor's eyes that is a heavier finding than having no control at all, because it shows the organisation does not know its own state.

Why Nobody Looks

There are three reasons and all three are reasonable.

Settings are scattered. Segregation of duties sits on one screen, password policy on another, masking in a third place, audit trail settings in a fourth. Walking through all of them and taking notes takes half a day, and nobody does that every three months.

The expected value is not written down. Seeing that a setting is on is not enough; you need to know what it should be. The expected value usually lives only in someone's head, and it disappears when that person leaves.

Change is silent. Turning a setting off is not as visible an event as deleting a user. Controls switched off temporarily and never switched back on are among the most common findings in an audit. The deliberate version of this, controls loosened before an audit, is the subject of its own article. We covered why a settings change should itself go through approval in the four eyes article.

What a Readiness Check Should Cover

The goal is to gather the scattered settings onto one screen and write the expected value next to each one. The scope can be grouped under seven headings.

• Segregation of duties. Can an approver execute, can a requester approve their own request, is a distinct approver required per step, are there enough people to approve, has an auditor role been assigned.
• Rollback and isolated trial. Is a rollback plan mandatory, is a trial environment defined.
• Request discipline. Is a ticket number required, is its format validated, is a separate number required for emergencies, does every server have an approval policy, are critical objects defined.
• Identity and passwords. Password rules, second factor coverage, whether the setup administrator's default password has been changed.
• Data protection. Is masking on, what is the delivery regime, are any servers exempt from masking, are sensitive data patterns defined.
• Audit and evidence. Is the audit trail key configured, is signing on, are anchors fresh, are records copied to a second location, is the SOC stream working, what is the delivery lag.
• External controls. Traces of whether management endpoints are network restricted, and transport security.

An eighth heading should be added and read separately from the daily controls: secret placement. Do passwords, keys and connection strings sit in the configuration file or in environment variables. This is a list to be closed before going live, not an ongoing governance control.

Two States Are Not Enough: The Third

The most common mistake when building such a screen is marking every row as passed or failed. Some settings have no right answer; they depend on the organisation and represent its deliberate choice.

An example: a server exempted from masking. That may be a mistake, but it may equally be a deliberate choice because it is a test environment. Marking it as failed produces a false alarm; marking it as passed hides a real gap.

The right design has three states: in order, attention and decide. The third says: there is a choice here, the choice itself is not wrong, but you should be aware you made it. That is also the answer to give an auditor: not "it had to be this way" but "we left it this way knowingly, and here is why".

The Number Itself Is Not Evidence

Running such a screen produces a number: this many controls in order, this many needing attention. Using that number as a score is tempting, and wrong.

The reason: controls do not carry equal weight. An unconfigured audit trail key and an empty critical object list on one server are not the same thing. An installation that closes twenty small items and leaves one critical item open looks good as a number and is bad in reality. In a governance measure the right approach is to look at the worst item, not to average. The same logic applies when setting the risk of a single change; we explained why it should not be an average in the risk band article.

The real value of the number is in the trend. If the count of items needing attention rises across quarterly measurements, something is loosening. What should be presented to an audit is not a single snapshot but the record that this measurement is taken regularly.

Who Should Run This Check

The team that builds the screen and the team that reads it should not be the same. A system administrator runs it to see the state of their own installation; that is an operational need. But internal audit or information security should be able to see the same output independently.

A reasonable rhythm is quarterly and after every major release. There is one moment that should not be missed: just before the audit date. Comparing that measurement with the previous one catches any control loosened in the run up to the audit.