Hey, welcome to VoraPrep Audio.
Let’s talk about something that sounds incredibly dry but can cost a company millions. IT governance documentation. I know, I know. But stick with me. There was this financial services firm, and a single vague sentence in their Acceptable Use Policy ended up costing them over a million dollars in fines. An employee shared sensitive client data using a cloud service they weren't supposed to. The policy just said to 'handle data securely' but never actually defined what that meant or which services were off-limits.
That's why this stuff matters. As an IS auditor, you're not just ticking boxes. You're looking for these exact kinds of ambiguities that can blow up in a company's face. Your job is to make sure these documents are clear, complete, and actually being enforced.
So, how do all these documents—policies, standards, procedures—fit together? The best way to think about it is like our legal system.
A Policy is the highest level. It's like a law passed by Congress. Think of a law that just says, "Thou shalt not speed." It’s broad, it's mandatory, and it states management's intent. It tells you *what* to do, not *how* to do it.
Just below that, you have a Standard. A standard is like a specific regulation from the Department of Transportation that puts a number on that law. It says, "The speed limit on this highway is 65 miles per hour." It's mandatory, it’s specific, and it's measurable. This is what you audit against.
Then you get to the Procedure. This is the driver's manual. It gives you the literal step-by-step instructions. "Press the brake pedal with your right foot to slow down." It's the detailed 'how-to' for a specific task. Mandatory for the person doing the job.
And finally, you have Guidelines. These are not mandatory. A guideline is like a defensive driving tip—you know, "Consider leaving a little extra space when it's raining." It's a best practice, a recommendation. Good advice, but you won't get a ticket for ignoring it.
So you've got Policy, Standard, Procedure, and Guideline. It's a hierarchy, flowing from big-picture intent down to specific, actionable steps. Quick check for yourself: can you think of one of each at your own job? If not, that could be a sign of a documentation gap right there.
As an auditor, when you walk into a company, there's a core set of policies you just expect to see. If one is missing, that's a pretty big red flag. The big one, the keystone, is the Information Security Policy. This sets the whole tone. From there, you'd look for an Acceptable Use Policy, or AUP, which tells employees what they can and can't do with company computers and internet. You'll need a Data Classification Policy that sorts data into buckets like Public, Confidential, or Restricted, and says how to protect each one. An Access Control Policy is critical—it defines who gets access to what, based on principles like least privilege. And of course, you need policies for Change Management and Business Continuity. Without these, the foundation of IT governance is shaky at best.
Now, these documents aren't just written once and then forgotten. They have a lifecycle, and you have to audit that whole process.
It starts with Development. You'd check to see *why* a policy was created. Was it in response to a new regulation or a new risk? And were the right people in the room—legal, HR, IT, the business units? You want to see that it wasn't just written in a vacuum.
Next, you look for Approval. A policy needs teeth, and that comes from senior management. You’re looking for a signature, a date, something that shows a C-level exec or a governance committee formally signed off on it.
Okay, so it's approved. But a policy nobody knows about is worthless. This brings you to Communication and Training. Did they just email it out once, or was there a real plan? You should be able to find training records, maybe even signed acknowledgements from employees.
After that comes Enforcement. This is where the rubber meets the road. Is the company actually monitoring for violations? And when they find one, what happens? You'll want to see a consistent disciplinary process. You'll also look for an exception process. Because sometimes there are valid business reasons to deviate, but those exceptions need to be documented and approved.
And finally, you check on Maintenance. The world changes, threats change. So policies need to be reviewed, usually every year. You'll look for a review schedule and a version history to prove these documents are being kept alive and relevant.
When you get a question on the exam about this, they'll give you a scenario and ask you to classify a document. Here’s a quick way to think through it. First, ask what its purpose is. Is it a broad statement from management? That’s a Policy. Then, check its specificity. Does it give you a hard number, a measurable rule, like "AES-256 encryption"? That's a Standard. Is it a 'how-to' guide with step-by-step instructions? That's a Procedure. And if it uses softer language, words like 'should' or 'consider' or 'best practice,' you're looking at a Guideline.
Let's walk through a real CISA-style example. Imagine you're auditing a fast-growing fintech company. They're moving their CRM to the cloud, and you're there to check their governance.
Your first move is to ask for their 'Cloud Security Policy'. Management comes back and gives you a general 'Information Security Policy' and something called a 'Vendor Management Guideline'. Hmm. You see the problem right away. There’s no specific, mandatory standard for how to configure things securely in the cloud. And that guideline for vendors? It’s not mandatory.
So what's the risk? Without a standard, a developer could accidentally spin up a server with a major vulnerability, like leaving customer data publicly exposed. It happens all the time. The lack of a formal policy for cloud vendors means they might not have done proper due diligence. This is a major control gap.
So what's your recommendation? The exam might give you a tempting technical answer, like "Recommend they install a Cloud Access Security Broker." And a CASB might be a good idea… later. But that's not the root cause. The root cause is a failure of governance. Your *first* and most important recommendation has to be for management to develop and approve a formal Cloud Security Policy and a supporting, mandatory Cloud Security Standard. You have to fix the governance before you can enforce the technology.
This brings up a pitfall a lot of people run into: mixing up standards and guidelines. Just remember this: Standards are mandatory. If you don't meet a standard, it's a control deficiency. It’s a finding you have to report. Guidelines are optional. They're just good advice. Choosing not to follow a guideline isn't a compliance violation. You have to be really clear on that difference.
If you need a simple way to remember the hierarchy, picture a pyramid. At the very top point, you have the Policy—that single, strategic direction from the top. The next layer down is wider, that's your Standards, the specific rules that support the policy. And the wide base of the pyramid? That’s all your detailed Procedures and Guidelines for day-to-day work. It helps you visualize that flow from general to specific.
As you're studying, remember that breaking down complex topics like this is what we focus on. VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. If this way of learning works for you, you can get started for free at Vora Prep dot com.
So, on exam day, look for those keywords. 'Must,' 'shall,' 'required'—that's policy or standard language. 'Should,' 'consider'—that points to a guideline. And a numbered list of actions? Almost certainly a procedure.
You’ve got this. Talk to you next time.