Auditing an Undocumented Process Without Owning Management's Controls

Thesis

An undocumented process is not unauditable. It usually means the auditor must separate three things that management may have blended together: the business objective, the risks to that objective, and the controls management actually performs. Internal audit can document that understanding in its workpapers, compare it with a reasonable criterion, and report design gaps without becoming the owner of management's control inventory.

For a CIA candidate, the exam point is precise: internal audit may provide assurance and advice, but management owns risk responses, control design, risk acceptance, and policy decisions. The auditor's job is to plan a risk-based engagement, develop sufficient evidence, and communicate the condition, criteria, cause, effect, and recommendation with objectivity.

Why No Documentation Does Not Mean No Audit

When management says, "There is no policy, so there is nothing to audit," the auditor should test that claim against the organization's objectives and risk universe. If the organization uses cloud applications, contractor tools, macros, external data stores, or employee-purchased software, then there are assets, data flows, access decisions, cost approvals, and cybersecurity exposures. Those facts create audit criteria even before a perfect policy exists.

The engagement can be framed as one of the following:

• Baseline assessment: compare current practices with a disclosed good-practice framework.
• Design review: determine whether management has designed controls that would reasonably address identified risks.
• Gap assessment: show where current practice does not cover the selected objectives or risks.
• Limited assurance review: test only the controls management says are actually operating.

The wording matters. A mature-control audit may say, "Control X did not operate for 8 of 40 samples." An undocumented-process audit may say, "Management has not defined ownership, criteria, and minimum control activities for this risk area; therefore, internal audit could not test operating effectiveness beyond the informal practices observed."

Worked Example: Keystone Medical Devices

Keystone Medical Devices uses a central IT service desk, but business units sometimes buy analytics tools directly with corporate cards. The risk register has a line for "unapproved cloud tools," but it does not identify specific risks, control owners, or required evidence. Internal audit wants to review the area after finance notices recurring charges for unsanctioned software.

The audit team should not write management's Shadow IT policy. It can, however, build an audit working map:

1. Objective: only approved cloud tools should store regulated product and customer data.
2. Risk: users may store sensitive information in tools that lack security review, retention controls, or access governance.
3. Expected controls: software intake, security review, vendor review, expense monitoring, access removal, and periodic tool inventory.
4. Actual controls: finance reviews merchant categories monthly, IT monitors single sign-on logs, and procurement maintains a partial vendor list.
5. Evidence: expense reports, SSO application logs, vendor onboarding tickets, exception approvals, and data classification review notes.
6. Gaps: no policy owner, no complete cloud-tool inventory, no risk acceptance record for exceptions, and no required remediation timeline.

The working map is an audit tool, not management's official control matrix. The final report can recommend that management create and approve its own risk-control matrix, but the auditor should avoid becoming the person who decides which risks are acceptable or which controls management will adopt.

Selecting Criteria Without Overreaching

Criteria can come from several places. The safest approach is to disclose the hierarchy in the planning memo and confirm it with the chief audit executive or engagement supervisor before fieldwork begins.

• Internal criteria: audit charter, risk appetite statements, IT strategy, procurement rules, data classification policy, incident history, risk register entries, and board-approved audit plan.
• External criteria: IIA Standards for engagement planning and performing internal audit services, COSO's objective-risk-control logic, NIST guidance for asset and resource protection, and CIS Controls for enterprise asset and software inventory.
• Entity-specific criteria: what management has already claimed in the risk register, committee materials, security roadmap, or regulatory responses.

Using an external framework does not mean the report must accuse management of nonconformance with every requirement in that framework. The auditor can scope the work to selected control objectives, such as "identify unauthorized software that stores company data" or "remove user access when a tool is no longer approved."

Assurance Versus Advisory Boundary

The independence risk is not created by asking management how it manages a risk. The risk appears when internal audit designs the control, chooses the risk response, or operates the process. A clean boundary looks like this:

• Internal audit may identify relevant risks, ask how management addresses them, compare actual practices with criteria, and recommend that management document ownership and controls.
• Internal audit should not approve the Shadow IT policy, choose the control owner, set the risk appetite, operate the inventory process, or certify management's risk acceptance decision.
• If internal audit facilitates a workshop, the work should be labeled advisory, the participants and management decisions should be documented, and later assurance work should consider whether objectivity safeguards are needed.

Fieldwork Pattern for the Exam

For CIA-style questions, use this sequence:

1. Confirm authority and scope in the audit charter and engagement plan.
2. Identify the objective and risk before listing controls.
3. Perform walkthroughs to understand actual practices.
4. Build an audit working risk-control map.
5. Select criteria and disclose the basis of assessment.
6. Test design before operating effectiveness.
7. Report missing criteria, missing ownership, or inadequate design as findings when supported by evidence.
8. Keep management responsible for remediation and risk acceptance.

The core answer is not "audit cannot proceed." The better answer is "audit proceeds as a risk-based baseline or design review, with clear criteria and a clear management-ownership boundary."