Your Validity Controls Need Authority and Access

Back to Topics

If you want to rely on your validity controls, they need to answer two related questions: Was the individual authorized to act, and did system access accurately reflect that authority?

For system-based transactions, effective validity controls need to address both.

One is the actual granting of authority — the process that determines who is permitted to act and within what limits. The other is the access control that restricts the system to the people who currently hold that authority.

Many agencies build the second and assume it covers the first.

Why It Matters

GAO's Green Book, Principle 10, §10.18, defines validity as:

That last phrase — "executed according to prescribed procedures" — is doing more work than it sometimes gets credit for.

Validity isn't only asking whether the transaction occurred and related to the entity. It also requires the transaction to have been executed according to prescribed procedures — and, where those procedures depend on delegated authority, whether the individual acting actually possessed that authority at the time.

In a federal environment, almost every financial process runs through a system: a contract writing system, a financial system, a workflow tool with approval routing built in.

That makes it easy to treat validity as primarily a system question:

Does the workflow enforce the right approvals? Does the system prevent the wrong person from taking the wrong action?

Those controls are necessary.

But they only work if the authority behind the system access is correct.

The Argument

Authority Is Granted Outside the System

Before any access control in a financial system matters, someone must first have the authority to act.

That authority might come from a contracting officer's warrant, a delegation of authority, a certification authority, or an established signature threshold.

The important point is that the system does not create the underlying authority.

It reflects it.

The source of that authority exists elsewhere — in a warrant, delegation memorandum, appointment, or other authoritative record establishing what the individual is permitted to do.

Access Control Is Supposed to Restrict the System to Match Authority

Segregation of duties and role-based access controls exist, in part, to enforce those boundaries inside the system.

They determine what a user can do:

• This role can requisition.
• This role can approve.
• This role can certify payment.
• This role can execute a particular transaction.

And properly designed segregation-of-duties controls prevent one individual from holding combinations of roles that create unacceptable conflicts.

But there is an important dependency underneath all of it:

The system's understanding of someone's authority has to match the authority that person actually holds.

If those two things diverge, the system can function exactly as designed and still permit an action the individual was not authorized to perform.

The Objection Worth Taking Seriously

A reasonable pushback is: "We have SOD matrices and role-based access control. Doesn't that cover validity?"

Not by itself.

SOD can demonstrate that the system prevents incompatible functions from being performed by the same individual. Role-based access control can demonstrate that a user cannot perform functions outside the permissions assigned to the role.

That's real assurance.

But it is assurance about the system's internal access logic.

It does not necessarily establish that the underlying authority supporting that access remains current.

A perfectly configured access-control matrix can faithfully enforce a role that should have been revoked six months ago.

The control performs exactly as designed.

The problem is that it is enforcing system access based on authority that may no longer exist — or may never have matched the access granted in the first place.

Closing that gap requires something outside the system: a current, authoritative record of who actually holds a warrant, delegation, certification authority, or other applicable authority, and a control that periodically reconciles system access against it.

A system can tell you what it was configured to enforce. It cannot, by itself, tell you whether the grant of authority behind that configuration is still good.

A Simple Example

Say a contracting officer holds a warrant authorizing actions up to $1,000,000.

Two years ago, when the CO was provisioned in the contract writing system, IT assigned a role allowing approvals up to $2,000,000 because that was the standard role template associated with the position at the time.

The CO's warrant is renewed this year at the same $1,000,000 limit.

Nobody revisits the system role because the warrant renewal does not trigger a corresponding access review.

Then a $1,500,000 modification comes through.

The system lets the CO approve it.

From the system's perspective, everything works. The workflow routes the transaction to the appropriate role. The role has permission to approve the amount. No segregation-of-duties conflict is identified. The transaction may subsequently be completely and accurately recorded in the financial system.

But the control environment has failed the validity objective because the action was not executed within the authority granted to the individual.

The CO's actual authority stopped at $1,000,000. The system allowed $2,000,000. And the access control had no way to identify the difference because nobody reconciled the system permission to the underlying grant of authority.

The system did exactly what it was configured to do.

That was the problem.

Three Objectives. Three Different Questions.

This is also where completeness, accuracy, and validity begin to separate from one another.

Those are different control objectives. A control designed to address one does not automatically provide assurance over the others.

A transaction can be complete because it was captured in the accounting records. It can be accurate because the amount, accounting classification, and timing were properly recorded. And the control environment can still fail the validity objective if the underlying action was performed outside the authority granted to the person who executed it.

For validity, system access is only part of the assurance.

A system can enforce exactly what it was configured to enforce and still permit an action that exceeds the authority actually granted to the person behind the role.

The Ask

Validity controls should answer two separate questions, not one.

Not just: "Does the system restrict this action to the assigned role?"

But also: "Was that role's authority actually granted, does the access match the scope of that authority, and is that authority still current?"

Take an hour this month and pull the system roles tied to warrant-dependent or delegation-dependent functions — contract awards, modification approvals, disbursement certification, and other financially significant authorities — and reconcile them against the current authoritative source.

Look beyond whether the roles create an SOD conflict.

• Ask whether the individual should have the role at all.
• Ask whether the dollar threshold in the system matches the authority actually granted.
• Ask whether expired, revoked, transferred, or modified authorities are reflected in system access.

If your access review only tests SOD conflicts and never checks whether the grant of authority behind each role is still good, you have a validity gap your system will never surface on its own.

If that reconciliation turns up a gap, you're not alone — it's one of the more common blind spots between access control and actual authority.

Validity is one of three information-processing objectives in the GAO Green Book. Get the full picture in the rest of the series: Completeness and Accuracy.

The views expressed in this article are those of the author and do not necessarily reflect the views of any employer, client, agency, or organization. Examples referenced are intended to illustrate broader internal control design concepts.