I hear from so many internal auditors that they do not feel qualified for a cybersecurity audit. I hear the same thing about IT audits. The way I see it, more advanced audits require specialized knowledge, but we already have a valuable starting point: internal auditors understand risks and how to test controls. We can apply those skills to cybersecurity while building our technical knowledge and bringing in support where the scope requires it.

When we look at a completed access review, we want to know more than whether someone signed it. We want to understand what the reviewer checked, whether the information was useful, and what happened when access needed to change. A folder full of approvals may show that an activity took place. The real question is whether it helped protect the organization.

As internal auditors, we approach cybersecurity control testing with two questions: Is the control designed to address the risk, and did it work as intended? We ask the same questions in any other audit. Management is responsible for designing, implementing, and operating controls. Our responsibility is to independently evaluate that design and test operating effectiveness.

Keeping those responsibilities clear helps us focus on the assurance we need to provide. Our conclusions should give leaders a reasonable basis for understanding where controls are working and where the organization remains exposed.

Start with the risk we understand

Before we ask for screenshots or select a sample, we start with what could go wrong. Could someone access customer information without authorization? Could a former employee retain access? Could an interruption prevent the business from processing orders?

We may need help understanding the technology, but we can use familiar audit questions to understand the process. Who is responsible? What triggers the control? How often does it operate? What happens when something goes wrong?

For a first engagement, we can define a manageable scope around a process such as employee access removal or periodic access reviews, after assessing the knowledge needed to test it. A focused audit gives us room to develop our understanding and produce a supported conclusion. The scope should reflect the team's capabilities and available technical support.

Evaluate whether the design addresses the risk

Our design assessment starts with a practical question: If people followed this process exactly as described, would it adequately address the risk?

For an access review, we want to understand which accounts are included, what information reviewers receive, and how they decide whether access is appropriate. We also want to know who removes access, how quickly removal should happen, and how unresolved decisions are escalated.

Imagine a manager receiving a spreadsheet containing account names and an approve or reject column. Without permission details or an explanation of what those permissions allow, the manager may have little basis for making an informed decision. Every approval could be completed on time while the control still has a design problem.

We can recognize that weakness using our understanding of control design. Technical support can help us determine whether the permissions and account types included in the review adequately cover the risk. Management owns the decision about how to improve the control; we explain the gap and evaluate the resulting design.

Follow the evidence through to the result

Once we understand the design, we test whether the control operated as intended during the period under review. A walkthrough helps us understand the process, but one successful occurrence does not establish consistent operation throughout the year.

With access reviews, we can trace selected decisions through to the system changes. If a reviewer rejected access, was it removed within the required timeframe? If removal was delayed, who followed up? Evidence of approval tells only part of the story.

The same reasoning applies to employee departures. We can compare departure records with evidence of account disabling and investigate delays. We also need to establish which systems and accounts should be covered. Disabling one central account may leave other access available, so understanding the environment matters to our conclusion.

Check the information we rely on

Before relying on a report, we need to understand how it was produced. Which systems are included? What filters were applied? Does the date range cover the audit period? Can we reconcile the population to a reliable source?

Questions about report reliability should feel familiar. We would ask similar questions before sampling payments or reviewing inventory records. Cybersecurity testing requires the same discipline around completeness and accuracy.

A vulnerability dashboard might show that nearly all identified issues were resolved on time. If critical systems were never included in the scans, sampling more closed tickets would not reveal the missing coverage. We may need a specialist to evaluate scanning configuration, but we can still identify the need to reconcile coverage with the relevant asset inventory.

Know when to bring in technical support

Confidence in our audit skills should go together with an honest assessment of what we can evaluate. Testing a process for reviewing access differs from assessing complex cloud permissions, firewall rules, or encryption configurations. Even a familiar process can involve technical dependencies that require specialist knowledge.

We should identify those needs during planning and involve someone qualified to evaluate them. Discussions with security teams help us understand how controls work. When we need independent technical assessment, we can bring a qualified specialist into the engagement and evaluate the work we rely on.

Learning enough to ask better questions is a practical goal. We need to understand the control objective, the evidence, and the limits of our testing well enough to support our conclusion.

Turn our testing into useful assurance

When we find an exception, we investigate its cause and extent. One late review may have different implications from a process that routinely excludes privileged accounts. We explain whether the weakness concerns design, operation, or both, and connect it to the business exposure.

Management determines and implements corrective actions. Our follow-up testing evaluates whether those actions address the cause and whether the control works. We should also be clear about the scope and limitations of the assurance we provide.

Cybersecurity Controls connects safeguards with the risks they are intended to address. As internal auditors, we already know how to make that connection. We can begin with a well-defined scope, apply our control testing skills, and build technical depth as we go. Our contribution comes from asking meaningful questions and obtaining evidence that supports the answers.

‍