தி অडිटর'ஸ் ফ්ರेම්: থിংकिং लाइక अন् IS अडிटर

An IS auditor isn't hired to find every bug or misconfiguration in a system. The job is narrower and, honestly, harder: figure out whether the controls in place give reasonable assurance that risks to the business are managed. That distinction changes how you approach almost every task, from reading a firewall rule set to interviewing a system owner.

Risk first, technology second

A penetration tester asks "can I break this?" An auditor asks "does this matter, and if it fails, what happens to the business?" Before touching a single control, an auditor tries to understand what the system does, what data it touches, and what would go wrong if confidentiality, integrity, or availability were compromised. This is why audit programs usually start with a risk assessment or a walkthrough, not a vulnerability scan.

Concretely: if you're auditing access controls on a payroll system, the first question isn't "is MFA enabled?" It's "what's the impact if an unauthorized person can change salary data or view PII?" Once you know the impact, you can judge whether the existing controls (MFA, approval workflows, segregation of duties) are proportionate.

Evidence over assertion

System owners will tell you things work. An auditor's job is to verify, not to trust. This means asking for artifacts: a screenshot of a configuration screen, an export of user access rights, a change ticket with approval timestamps, log entries showing a control actually fired. If someone says "we review access quarterly," the auditor asks to see the last three review records, not just the policy that mandates it.

This evidence-based habit is what separates an audit finding from a hallway conversation. A finding needs to survive scrutiny: what was tested, what population was sampled, what criteria were used, and what was actually observed. Vague statements like "controls appear adequate" don't hold up in a report that management and regulators will read.

Design vs. operating effectiveness

One of the most useful mental splits in this field is separating control design from control operation. A password policy that requires 14 characters and MFA is well-designed on paper. But if the last access review was 11 months ago, or if service accounts are exempted without documentation, the control isn't operating as intended. Auditors test both: does the control exist as described, and is it actually being followed day to day?

This is why sampling matters. Testing one user's access doesn't tell you much. Pulling a sample of 25 terminated employees and checking whether their accounts were disabled within the SLA window (say, 24 or 48 hours) gives you a defensible basis for a conclusion.

Segregation of duties as a recurring theme

A huge share of audit findings trace back to segregation of duties (SoD): the same person who requests a change also approves it, or a developer has direct production database access alongside deployment rights. Auditors look for these overlaps constantly, because SoD failures are how fraud and unintentional errors slip through without a second set of eyes catching them.

When reviewing an environment, ask: who can initiate an action, who can approve it, and who can execute it? If one person holds two or more of those roles without a compensating control (like detailed logging reviewed by someone else), that's a gap worth documenting.

Writing findings that get fixed

A technically correct finding that nobody acts on is a wasted audit. Good findings state the condition (what was observed), the criteria (the policy or standard it violates), the cause (why it happened), and the effect (what risk this creates) — the classic 4C structure many audit shops use. Vague findings like "access controls need improvement" get ignored. Specific ones like "14 of 25 sampled terminated employees retained VPN access for more than 5 days past their termination date, violating the 24-hour deprovisioning SLA in policy SEC-014" get remediated because the owner knows exactly what to fix.

Building the habit

You develop this frame by practicing it on ordinary systems, not just formal engagements. Pick an application you use daily and ask: what's the risk if it fails, what controls exist, and how would I prove they work? Do this enough times and the auditor's instinct — skepticism paired with a demand for evidence — becomes automatic.

If this kind of control-and-risk thinking interests you, check out Korra Studio's segments on access control models and security governance frameworks for a deeper technical grounding.