CISM EXAM PREP - Domain 3A - IS Program Development

Welcome back to the CISM exam prep series. So here in domain 3 part A, we'll focus on development of the information security program. We'll talk about program resources, the people, processes, and technologies that come together to form the information security program. We'll walk through the system development life cycle before we dig into the process of asset identification and classification, including the key activities of the secure data life cycle. We'll talk through the types of standards and frameworks that can guide and accelerate your efforts in developing an information security program. Now, while you're not expected to be tested on frameworks directly, you should be familiar with where and how they can support your efforts. Then we'll talk about the documentation that supports an information security program, including the policies, procedures, and guidelines. And we'll wrap with a look at the considerations for program metrics to ensure we can measure progress and course correct along the way.

Welcome to domain three of the CISM exam prep series which focuses on the information security program. Here in part A we'll focus on security program development. And while you may know me from my exam prep content here on YouTube, in my nineto-5, I'm a cyber security strategist and a VCSO for a regional bank where I'm exercising my cyber security knowledge every day like that which you'll find here on the CISM exam. More importantly, last year I helped thousands achieve cyber security certifications like the CISSP, CCSP, and the Security Plus exams. And I'm bringing that proven formula to you here with the CISM exam. As with all my exam prep courses, you'll find a PDF copy of this presentation available for you in the video description to leverage in your exam preparation as you require. You'll also find a clickable table of contents available in the video description and it should appear automatically on your YouTube video timeline.

So domain three focuses on the information security program and by volume it's roughly onethird of the content you can expect to see on the exam. So it's quite large in that respect. We have four domains and like the others domain three is divided into a part A and a part B. We'll be focused on part A here today. So if we look at domain 3 by topic, we're focusing on program development in the first half of the domain including program resources, information asset identification and classification. This is where quite a lot of foundational knowledge is expected. I'll cover that to make sure that we fill any gaps you might have in your experience. We'll talk about industry standards and frameworks, policies, procedures, and guidelines. and we'll wrap with a look at information security program metrics. When we move into part B in our next installment, we're talking about a logical progression from development to management. And part B will focus on control, design, selection, implementation, and essentially the more hands-on aspects of this topic, but today program development.

Now let's take a look at the supporting tasks of the 37 total that align with domain 3A. So we have number five. Establish and maintain information security policies to guide the development of standards, procedures, and guidelines. Policies capture leadership expectations and guide behavior. Number 10, evaluate and report information security metrics to key stakeholders. So remember metrics should be measurable and relevant. And if I were to add a third adjective there, they should also be actionable. 11. Establish or maintain the information security program in alignment with the information security strategy. So this provides a structured approach for managing and protecting an organization's information assets on the whole. 12. Align the information security program with the operational objectives of other business functions. Remember security is about keeping the business running securely. Security exists principally and solely to support the business. 13. Establish and maintain information security processes and resources to execute the information security program. At the end of the day, documented processes ensure the team gets it right even in stressful circumstances. It also eliminates any disagreements over what policies and processes are due to lack of documentation. 14. Establish, communicate, and maintain organizational information security policies, standards, guidelines, procedures, and other documentation. So the direction comes from the top but is documented and communicated throughout the organization. And 20 establish and or maintain a process for information asset identification and classification. Remember assets need to be identified, classified and be assigned an owner.

And we're going to start with section 3A1 which is program resources. So we'll look at the essential elements that we need to develop our program. We'll talk about the business case, the scope and charter. We'll look at defining and creating our road map. And we're going to talk about life cycle principles specifically around the system development life cycle.

So let's answer the million-dollar question. What is an information security program? So the program is the execution of your security strategy. It combines the people, the processes and the technology to protect the organization's information assets. The purpose is to translate the highle security goals from your strategy into practical enterprisewide security controls and to manage them effectively over time. So your program should always align with business goals and its operation should be viewed as a continuous adaptive process. It's just a continuous adaptive loop. If I were to put that into an analogy, governance sets the rules of the road, the laws. For example, strategy plots the route and the mode of travel. And the program is the car making the trip. The program is the execution of that strategy.

So let's talk about the six outcomes of information security program management. An effective program aims to achieve six goals that we call outcomes. There's strategic alignment. So ensuring security directly supports business objectives and risk tolerance. I'm sure it's second nature to you now. Supports business objectives is a theme we hear over and over again. And it aligns to our risk tolerance. Risk management identifying, assessing, and mitigating risks to information assets to an acceptable level within our risk tolerance. At our risk appetite level, there's value delivery. This is providing coste effective security that enables not hinders the business. Security investments must show benefit. Remember the program's basic functions are to protect assets, ensure compliance, enable incident response and to reduce liability. So the other three outcomes resource management basically optimizing the use of people, budget and technology for security performance measurement. So using metrics to track effectiveness, demonstrate success of the program and justify investment. Remember, if you can't measure it, you can't manage it. Our metrics have to be measurable. They have to be relevant and preferably actionable. Assurance, process integration. So, working with other functions like audit, compliance, privacy, and physical security to provide a holistic view of risk and assurance. But for the exam, you should know these six outcomes because they represent the goals of program management.

I want to take a moment and refresh your memory on exactly what assurance processes means. We're talking about the systematic methods and activities that confirm to the organization stakeholders that security controls and policies are effectively implemented, operating as intended, and aligned with the organization's overall risk management and compliant goals. So a few examples here would include risk assessments, security audits, vulnerability scans, penetration testing, and compliance reviews. All assurance processes.

So who is involved? Let's talk about key roles and responsibilities in development of the information security program. The one that's most meaningful to you is the information security manager, which is effectively your role. That's you for purposes of this exam. The information security manager leads program development, implementation, and ongoing management. They bridge the gap between business needs and technical security operations. And they do need business acumen. They need to understand budgeting, risk, people management beyond just the normal technical skills that an information security manager would have from previous experience in their career. So they're really wearing multiple hats in that respect. Then there's senior leadership in our board which provides sponsorship and authority through the charter resources like budget and staff and holds ultimate responsibility for information security. At the end of the day, our senior leadership are the ones who are accountable and they need regular updates on security posture. Again, making sure that we tailor our communication to our audience so it's meaningful to our leadership. We have stakeholders. These would include management, business units, IT, HR, legal who all need to buy in and cooperate if we're going to be successful. And we'll use tools like REI charts to clarify roles. There's a security steering committee which is often used to ensure ongoing alignment with business goals and to facilitate decision- making. It's how we can get the different business units on board.

The next question is how do you build and manage the program? So that what's the development process? So it starts with the foundation understanding business objectives and performing risk assessments which give us the information we need to go in and then perform risk analysis on specific asset threat pairs. There's the charter which is the formal document granting authority and defining the program's objective, scope, leadership and funding. So at this point we have our resources. The road map, that's the strategic plan outlining how the program will achieve its objectives over time. It links the strategy to specific initiatives, which means the road map is often phased out. So, we have checkpoints along the way as we complete smaller projects throughout that road map implementation. So developing the road map means aligning with business strategy using frameworks as our guide. Frameworks like Cobbit ISO271 then assessing the current security state. Defining our desired target security state analyzing the gaps performing gap analysis. Creating an action plan again prioritized initiatives, timelines and resources. And then we implement and monitor using metrics that are relevant, measurable and actionable because the fact of the matter is conditions may change along the way in the course of our road map. So we might need to course correct along the way. Then we have frameworks and architecture. So I'd mentioned we use frameworks as guides. So we use established frameworks or enterprise architecture principles to structure the program ensure that our approach is consistent and we integrate security effectively throughout the life cycle because architecture isn't just technology it includes business processes and data flows but ISO NIST coat it's understanding what frameworks are for for the exam they're not going to drill down in the CISM into the nuts and bolts specifics of any of these frameworks. works. And then there's the business case. So a business case is how we justify major initiatives by demonstrating value, risk reduction, feasibility. We're using business language, linking budget request clearly to the strategy and the roadmap. And we integrate with the system development life cycle throughout. Security has to be built into all phases of the SDLC because remember you'll be tested potentially on the CISM to know that implementing security integrating security into the process from the beginning from design onward is going to be less expensive than bolting it on after the fact. So from the start don't bolt on later is key for cost optimization and minimizing disruption in later phases and continuous improvement. The program needs ongoing monitoring, review and adaptation based on metrics, changing threats and the evolution of the business. So we need to potentially adjust along the way. And we hear that theme continuously as well that we need to consider the program a continuous adaptive process because security is not static.

So let's talk about common challenges and constraints. So the first is lack of executive support and sponsorship. This is going to be fatal. Developing your information security program fails if you don't have support from the top. So we have to establish our budget requirements and make sure that we have skilled staff in place who can help with the implementation. And if we don't have skilled staff in house then that means we need to increase our budget to bring in outside support potentially. And it goes beyond that because there's also the reality that people don't love change and we're going to have at least some people internally resisting change. We need to educate our staff. So that needs to factor in to our time, our effort and our budget. Misalignment with business goals. So security may be seen as a blocker in some organizations. So there needs to be that process to develop consensus across the business units to make sure that the business units and the key leaders within the business units are on board. And that's where techniques like workshops, security steering committees, you know, opportunities to bring those business leaders in so they can make their concerns heard. And once people are heard and they hear that those concerns are addressed, then building consensus tends to be easier when it's not a one-sided authoritarian effort. It's collaborative. Then there's complexity. Technology, regulations, business processes. Aligning all of these to a solid outcome is not always a simple task. So we need to measure twice, cut once, right? So we need to plan for that complexity, develop a phased approach so we're not biting off more than we can chew in single implementations that may cause operational challenges because it may be simple enough to put technology in place and even to configure that technology to meet our regulations. But then we have to think about our operational processes and the people behind it to make sure that we have the right education and operational readiness established before we go all in in production. Poor metrics or measurement. If we can't show value or progress, if we haven't identified measurable, relevant metrics, not only is that going to be problematic in demonstrating value to leadership, it's also going to hamper our ability to identify misses that indicate a need for course correction. So those metrics are absolutely key in the ongoing monitoring, reporting and and management. Scope creep or poor project management. So a failure to set the target and manage the implementation is going to be problematic both to our implementation schedule and potentially to our budget if we have scope creeping in additional requirements either because we're allowing folks to throw their wants onto the pile or perhaps we didn't do the right planning up front, we didn't talk to the right stakeholders and we missed some required scope early on. that's going to be problematic to our schedule and our budget.

So you should be familiar with the systems development life cycle. There's not one universal answer. I'm going to give you the SDLC from the Isaka perspective. So a pretty practical approach I think. So it begins with initiation where we define and align security requirements. We then develop and acquire. This is where we incorporate our security controls into the solution. Implementation. This is where we're going to test and validate our controls, operations and maintenance where we monitor and update the controls over time as necessary as conditions dictate. Then of course when we get to the end of this the life cycle we have disposal where we archive, retire or destroy as necessary. So just to lay these out with a bit more detail applicable to the CISM exam. So it begins with initiation where we define and align highle security requirements with business objectives. Then development and acquisition where we incorporate security controls into system design and code. Implementation where we test and validate these controls before going live in production. Then operations and maintenance where we monitor for vulnerabilities and we update controls as needed. and finally disposal where we securely remove or archive data and decommission systems. So it doesn't end here. So within these phases are proactive activities that ensure the security program remains effective and up to date. So this would include integrating change management. So aligning life cycle activities with change management processes to ensure that changes are documented, that security is in the loop. so they can conduct any tests to make sure that security controls remain effective. Regular updates. So each phase of the systems development life cycle should include specific security considerations to ensure that we have secure development, testing, operation, maintenance and disposal. So every phase is secure. And then there's risk mitigation. So applying consistent risk management practices throughout the life cycle is going to minimize service disruptions. It's going to maintain data protection and support continuous improvement of the security program. So implementing the SDLC takes some effort, but operating in this way does definitely deliver some benefits. So through the life cycle, we're going to see benefits to the information security program itself because number one, integrating security at each stage helps avoid expensive disruptive fixes later. Remember that when we shift left with our effort in security, it's going to be less expensive than if we wait until we release a service and then try to bolt on security after the fact. It also ensures continuous risk management and compliance with relevant regulations. And by documenting and evaluating our controls throughout the life cycle, organizations can more effectively communicate risk and maintain a secure environment.

That brings us to the end of section 3A1. Let's test what we've learned with a practice question. Our question, the information security manager has developed a document to describe the information security program's mission, vision, roles and responsibilities and processes. What do we call this document? Is it a a guideline, b a policy, c a standard, or d a charter? These are all useful inputs to our effort. There are two that we can eliminate right away. The guideline, which gives us guidance on best practices for various functions, is really more about how we do something, not describing what the elements of our program entail. And we can knock out standard for a similar reason, more about how than what. That leaves us with policy and charter. So we'd see policies developed coming from leadership. Charter also coming with input from leadership. The right answer here is D. The charter which is specifically that document that describes the various facets of a function or a program. It's the scope and charter that would be relevant in this case. And if you're cloudy on the charter or scope and charter, you can go back and revisit that concept in domain one part A in this series.

And that brings us to 3A2 which is information asset identification and classification. So here we'll talk through the information life cycle, classification, valuation. We'll look at integrating classification with risk. And we're going to then cover some foundational technologies around data protection. Some of that technical knowledge you need to bring with you into the exam that you won't be tested on directly. And we'll talk a bit about risk likelihood and impact in the context of information assets.

So your job as an information security manager is to protect the crown jewels of the organization cost efficiently. So you're protecting the valuable assets. But to do that you first need to figure out what the valuable assets are, where they are, and how valuable they are. So I want to give you a streamlined look at the key points that you need to know for the exam. So it starts by identifying and valuing our information assets. Then classifying our assets and we need to understand the information life cycle and the context for data protection throughout that life cycle. So let's dig in.

So step one, identify and value your information assets. So what's an asset? Well, it's anything valuable that supports the business. This includes data of course, customer list, trade secrets, personally identifiable information, protected health info, financial records, its systems, facilities, personnel, even reputation and intellectual property. So, inventory is key. We have to inventory our assets. We need a process to discover and list all of our relevant assets and then determine each asset's worth to the business. And the valuation of an asset will be a product of its criticality to business critical processes and its sensitivity. So criticality, how essential is it for operations? What happens if it's unavailable? And then sensitivity. How damaging would it be if confidentiality or integrity were compromised? And then the tangible versus the intangible. So valuation of things like hardware is easy because we're just calculating replacement cost. information and intangible asset value like brand reputation or customer trust is harder, but it's often much higher value. It's harder to come to that figure, but it's a high dollar value. Think about the cost of a data breach, for example, the fines, the lawsuits, the lost business, the loss of customer trust that may be difficult if ever it can be regained. But don't underestimate intangible value. Ignoring it leads to flawed risk assessments. So why do we bother with valuation at all? Well, valuation directly informs risk assessment. So that allows us to calculate likelihood and impact and our cost efficiency or cost efficacy formula. So knowing the potential impact, the cost, and the damage of a compromise helps you decide how much effort and money you're going to spend protecting the asset, but it also allows you to prioritize the assets you need to spend time protecting.

And then our next step is classifying our information assets. So the purpose here is based on valuation on criticality and sensitivity to assign a classification level. And the goal here is to ensure that our asset gets the appropriate level of security controls throughout their life cycle as the sensitivity of that data may change over time. And I'll get deeper into both classifications and the information life cycle with you here in just a minute. But for example, you don't protect public marketing material the same way you protect secret merger and acquisition plans. One of those is obviously much more sensitive than the other. But classification drives consistent data handling and protection. So here are some sample data classifications. I pulled these straight from the CISSP study material that I created for students. And there is no one right set of classifications. What you see here are the government classifications that include unclassified, confidential, secret, and top secret going higher in order of sensitivity. And then you see a non-government or commercial equivalent on the right side there going from public through sensitive private into confidential and similar language describing the impact if that data were leaked. And there's no one right answer. I find this would work either of these sets of classifications would work great for many organizations. I do find many organizations choose their own names and generally speaking they will choose between three and six classifications for data balancing clarity of the type of data that they are classifying and simplicity not having so many classifications that it's difficult to keep up with.

And then step three understanding the information life cycle. And for the exam, you won't be tested on one specific model, but you do need to understand data protection needs from cradle to grave. So think functionally. We'll walk through the steps and then I'll give you a visual here. So it starts when we create the data. The data is born. Whether it's a user creating a file or a system creating a log for example. As soon as that data is created, we want to classify. We assign sensitivity early because that dictates handling rules. We're going to store that data. And when we're storing data, we need to protect it at rest. So that's encryption and access controls based on classification. When data is in use, such as in transit across the network, we're going to use TLS encryption for example, or VPN perhaps. And when it's in use in an application, access controls, data loss prevention based on its classification. When we archive that data, we're going to retain it securely if it's needed for compliance or business reasons that we're retaining. And when we destroy, we will destroy securely so it can't be recovered through forensic means when it's no longer needed. And that's going to minimize risk. So let's just step through the secure data life cycle. This is purely a functional version. There's not one right answer for the CISM exam. It's more important that you just understand the process from a functional perspective. So we create data, classify, store, use, archive, and ultimately destroy. So data can be created by users like a user creating a file or a system generating a log file. We're going to classify that data because data can only be fully secured when its sensitivity is known. So it should be classified as soon as possible after creation bearing in mind that throughout its life the sensitivity of a document for example may change because the data within that document may be updated and so data that changes within a document may trigger a change in its classification that can certainly be reclassified manually. Many organizations will use software that will identify the need for those changes automatically. When we're storing the data, we're encrypting at rest. We might use an algorithm like AES, which is the gold standard for symmetric encryption. In fact, the Department of Defense in the US military uses AES 256 to encrypt their top secret data. And when data is in use, we're going to protect it with adequate security protocols like access control list and data loss prevention. And when in transit over the network properly encrypted using TLS for example, archival is sometimes needed to comply with laws or regulations requiring the retention of data. Uh a lawsuit litigation may trigger the need to retain data. So we're going to retain that data as long as we are required to do so. And the moment we no longer need that data, we're going to destroy it in such a way that it is neither readable nor recoverable even through forensic means. The fact of the matter is data retained longer than necessary increases our risk. Data that we've securely destroyed when it's no longer needed is data that cannot be stolen by an attacker, accidentally leaked by an employee oversharing, or requested by opposing legal counsel as part of litigation. We want to comply with the law and retain data as long as it's necessary, but destroy it when there is no business reason to keep it any longer.

And step four, I want to talk to you about some practical valuation approaches. So perfect financial valuation is hard, especially for the intangibles. And you don't want to get bogged down looking for exact numbers. You want to get a good ballpark figure, an order of magnitude, if you will. So focus on consistent methods. Use a repeatable process, even if approximate, to justify your security spending based on the valuation. So loss scenarios, estimate costs, downtime, fines, reputation damage for specific events like ransomware attack, insider theft, data breach, and you know, in line with our earlier discussions in this series, making sure that we're focused on high probability and common scenarios. We're not wasting time on edge cases. And in terms of methods, we talked about qualitative, quantitative, and hybrid back in domain 2, risk analysis. So qualitative being the subjective, quantitative being the objective that comes down to dollar values and hybrid that combines the two. So key takeaways here, effective information security starts with knowing your assets, understanding their value, especially the intangibles, and classifying them correctly. And this drives riskbased decisions and ensures you apply the right level of protection where it matters most throughout the entire information life cycle.

Now when it comes to risk assessment, I just want to touch on the process there one more time so we can connect the dots between the business side of the house and the information security function. And risk assessment begins with that inventory of critical business assets. So, we were just talking about information assets. It really goes beyond that when we're thinking about the broader range of assets that we need to secure, but the process is not entirely dissimilar. So, we identify risks. We assess those risks. We apply appropriate controls to mitigate the risk. We're going to monitor and report over time and potentially change our controls or alter our controls when they are not as effective as they need to be. And that will lead to just a continuous adaptive loop. But the business process owners drive that inventory of critical business assets. The technology side of the house needs to collaborate with the business side of the house because we can't assess risk if we don't have a good inventory of the assets. So the security team can drive that risk assessment but not without a good asset inventory.

Before we get too far away from the information security life cycle, I want to talk through some data protection technologies. Some of that foundational knowledge I mentioned you should take with you into the exam for this particular part of the syllabus. So, we'll start with digital rights management, which allows content owners to enforce restrictions on the use of their content by others. It's commonly used to protect entertainment content like music, movies, ebooks. So, DRM is the protection you'd see on ebooks in your Amazon Kindle, for example. It's occasionally found in the enterprise protecting sensitive information stored in documents. I'd say that's a relative rarity. Much more common is data loss prevention which is a way to protect sensitive information and prevent its inadvertent disclosure. It can identify, monitor and automatically protect sensitive information in documents. We can configure automatic classification and protection with many DLP solutions based on the content of the documents and it monitors for and alerts on potential breaches, policy violations like oversharing for example and the protection travels with the document file or other data preventing any local override of DLP protections. And to say it another way and give you a bit of additional context, DLP is a system designed to identify, inventory, and control the use of data that an organization deems sensitive. And DLP technologies can span several categories of controls. They can be detective, preventive, or corrective in nature depending on the features you enable. Oftent times with cloud solutions, it depends on the features you pay for. And policies can typically be applied to email, SharePoint, your cloud storage like one drive for example that's storing documents, removable devices like USB keys and even relational databases. And then there's the cloud access security broker or CASBY for short, which is a security policy enforcement solution that may be installed on premises or in the cloud. It's almost always a cloud solution these days and intended to focus on protection in cloud scenarios quite often. So shadow IT was where CASBY got its start. It's expanded well beyond the prevention of shadow IT in 2025. Now I want to just juxtapose these three technologies side by side so you get an appreciation for the scenarios in which they factor in case you don't have a lot of experience in this area. So the focus of each of the three so DRM remember is content protection and access control typically and entertainment content. DLP is data leak prevention and sensitive information protection. So it's going to give us a way to classify and protect data generally with a way to automatically classify and label data and that protection traveling with and then the CASBY is cloud service security and visibility often focusing on use case scenarios around cloud storage. the scope DRM primarily digital content and software DLP really all sensitive data within an organization and CASBY specifically in the cloud service scenarios I see cloud service scenarios with CASBY typically revolving around document content that we're trying to keep in specific repositories and not being exfiltrated you know leaked into Box or Dropbox or other third party repository tories. So your primary users with DRM, it's going to be content creators, publishers, distributors. We don't really see DRM in the enterprise much. DLP will be organizations handling sensitive data of all kinds. DLP is pervasive in the enterprise today and in small and medium business for that matter. It's pretty common to see it as well. The CASBY will really be in organizations heavily utilizing cloud services and the implementation. So DRM is embedded in your content or software. DLP is going to be network endpoint or cloud-based. Cloud-based is what I see almost always these days. And then CASBY is going to be as a cloud service or an on premises solution almost always again cloud service and all protect data but they cover different use cases. So that should give you some context if you're not terribly experienced in this area.

So let's talk about data collection. So there's purpose limitation which means we use data that we collect only for the specific purposes that were disclosed when we collected it. For example, if data was collected for notification purposes, don't later use it for marketing just because you want to. And then there's data minimization. So this principle states that we only collect the necessary data required to fulfill the specific purpose that we're collecting it for. So, we collect the minimum amount to meet the stated purpose and manage retention to meet regulations. For example, if you only need someone's age category for marketing, like if you need to know if it's someone over the age of 13, don't collect their exact birth date, just get their age. Data masking. So when we see only partial data left in the data field for example, you'll see this commonly with credit card data where you have the asterisk and then you just see the last four digits. This is commonly implemented within the database tier but it's also possible in code in your front-end applications. So what it is is more important in this case versus where it's implemented. And then there are obfiscation techniques. So anonymization for example the the process of removing all relevant data. So it's impossible to identify the original subject or person only effective if you do not need the identity data once you've anonymized that data. You're not going to be able to reverse it back to identify the original subject. tokenization, which is where meaningful data is replaced with a token that's generated randomly and the original data is held in a vault or other repository. So, it's stateless. It's stronger than encryption. The keys aren't local. There's also pseudonymization, which is a deidentification procedure in which personally identifiable information fields within a data record are replaced by one or more artificial identifiers or pseudonyms.

So let's get back to integrating asset classifications and risk structures. I want to give you a couple of practical approaches. So for example, we have the top-down approach where we start with business functions and work down to the individual assets for those critical business functions identifying their specific risks. And then we have a bottomup approach where we start with the individual resources, the individual assets, identify their risks, and then map them up the chain to the critical business functions they support. So if I had a business process owner in the room, it might be easier to take a top down approach. It might be more practical. If I have just the IT folks, it might be easier to take a bottom up approach or I might do a round of each. So if we dig in a bit deeper here, the next logical step after you identify and classify assets is determining their criticality and understanding impact. So knowing what you have is the first step. And then knowing how bad it hurts if something goes wrong is step two. And that's going to be very important for prioritizing your security efforts and justifying the controls and the cost of those controls and the effort it takes to put them in. So, we'll want to go through some steps here to sharpen our definitions, identify the impact. You do want to make sure you keep the classification levels practical and link those classifications to the requirements for handling those assets. And then we have that ongoing monitoring and review phase. So, let's dig into these. So, sharpening our definition, sensitivity versus criticality. So think of sensitivity primarily in terms of confidentiality, integrity and availability. So what's the damage if this data is leaked, altered or suddenly unavailable? That often relates directly to the data itself. And then we think of criticality in terms of business operations. How essential is this asset system process data? How essential is this asset to business operation? And if it goes down, what core functions stop? And how long can we survive without it? Next is the business impact analysis. And this is very important. It's how we formally assess the consequences of disruption to critical business processes and the assets that support them. What it does is identifies dependencies or allows us to identify dependencies, which processes rely on which assets. It quantifies the impact over time including financial loss, any regulatory fines we can expect, reputation damage, one of those intangibles, operational breakdown. So for the CISM, the BIA provides the evidence to determine asset criticality and to justify the level of security controls needed. CISM has a really strong focus on coste effective security, right? But the BIA connects security requirements directly to business pain points. That business alignment we've talked about repeatedly. And then keeping the classification levels practical. You do need different classification levels to apply appropriate controls. But you don't want to over complicate it. Too many levels become confusing and hard to manage consistently. In the real world, I see classification levels between three and six. And most of your providers out there are going to tell you don't go over half a dozen or so if you can help it because it becomes confusing to folks as they try to classify their own data in some instances. But find the balance enough tears to meaningfully separate risk levels, but few enough that people actually understand what you have in front of them and they can follow the rules. Aim for balancing clarity and usability. And then linking classification to handling requirements. The whole point of classifying assets is to dictate how they must be protected. Your classification scheme needs to define specific handling rules for storage. We might find that not only are we encrypting data, but data in specific server locations. For example, if we have a server that hosts an app for legal, that all of the documents and data there get a specific classification because of their function. And then for data in transport, we need to encrypt and transport. we typically use TLS. Maybe we're sending hard drives off for long-term storage and for those physical devices, we use a secure courier to get the drives or maybe physical documents over there. And when we're transmitting very sensitive data on networks, maybe we only allow that data to traverse specific networks where we have control and know what security is in place exactly. And then access controls, who can view and modify? Who's managing the access control list? Do we need to put a need to know rule in place? But remember, you need to ensure controls match the classification level throughout the data life cycle. And the security of the systems that are being used to access that classified data, whatever its level, need to match. So the systems used to access the data should be classified at the same level as the data or higher. And then the ongoing monitoring and review is mandatory. So remember businesses change, threats evolve, the value or criticality of an asset can certainly shift over time. So we need periodic review of our asset classifications, our valuations and basically a re repeat of that business impact analysis on a periodic basis will be important because that ensures our security program stays aligned with current business objectives, our risks, our regulatory requirements. And if we let that classification scheme get outdated, it leads to either overspending or unex unacceptable risk exposure. We going to drift one way or the other, but neither will be good. Bottom line, determining criticality isn't just an academic exercise. It involves using tools like the BIA to understand our real world business impact, setting practical classification levels and defining clear handling rules based on those levels. and then continuously reviewing everything to ensure that your security efforts remain focused on protecting what truly matters most to the organization today at the current time. Remember the CISM and Isaka really see this as a continuous adaptive loop.

That brings us to the end of this section. Let's apply our knowledge with a practice question. Our question, a security manager has developed a document that describes required methods to protect information at rest, in transit, and in use. This is known as an asset classification policy, an acceptable use policy, a data loss classification policy or a data classification policy. So looking at the question here the key ask is that the we identify the document that describes required methods to protect information. So this is data focused but protecting information at rest in transit and in use. So it's definitely not an asset classification policy because it's focused purely on information on data. It's not an acceptable use policy. This isn't giving users guidance on acceptable use. So in this case, it's going to be something related to data. The right answer here is a data classification policy. So it's giving us actions that we need to perform before loss, which makes it a data classification policy, not a data loss classification policy. But that's what your data classification policy does. It defines the different levels for data together with procedures and standards for protecting that data at each classification level. So that's going to include the label, the encryption, and some restrictions around who can access it for example. And it should include various use cases, not just your unstructured data like document data, but we need to incorporate structured data in there like our relational databases.

That brings us to section 3A3 which is industry standards and frameworks. We're going to go through framework types and talk about their function. This is going to be a bit more academic in nature but important that you understand the purpose of these frameworks. But for the CISM exam in particular, you need to understand how different frameworks and architectures can help you build and run an effective information security program that aligns with the business over memorizing specific controls or framework steps. They're not going to test you on those. They're really testing you more on application. So focus on their purpose, their application, and how they interrelate. Don't memorize. But we'll talk through key framework distinctions. We're going to look at enterprise information security architecture and its importance information security management frameworks and then essential framework components the building blocks of your program.

So let's start with key framework distinctions. We have control frameworks that focus on what specific controls to implement be those technical, administrative or physical. Examples here would include uh the CIS framework ISO 272 which is the sort of sister document to ISO 271. So 272 provides guidance on the controls to implement for 271. NIST 800-53 that special publication specifies security and privacy controls for information systems and organizations. And then PCIDSS is industry specific for credit card processors. Risk management frameworks focus on how to identify, assess, treat and monitor risk. So here we have ISO 2705, ISO 31000, the NIST cyber security framework, which is a NIST document aimed at non-government entities, and then NIST 800-37, which is better known as the NIST RMF or risk management framework aimed at government agencies. Security program management framework. So these focus on how to establish, manage, govern and continuously improve the overall security program. So ISO 271 falls into this category, the NIST cyber security framework aimed at non-government, Cobit and ETSI. Don't get too worried about all of these many letters and numbers yet. I'll give you some guidance on where to read more about these frameworks and I'll give you a bit more even in this session. But you want to know the purpose of each framework type for the exam. That's your key focus. Understanding the purpose of some of the more common frameworks doesn't hurt either.

And then there's the enterprise information security architecture. So this is the security blueprint within the overall enterprise architecture. It basically aligns security requirements, solutions, and processes with the business strategy and the general IT infrastructure. Think of it as ensuring security as part of the design, not bolted on later. Remember, it's going to be less expensive if we implement security throughout the process from design onward. The core purpose is to provide structure, consistency, and a roadmap for security that supports business objectives while managing risk. So managing the risk to confidentiality, integrity and availability, the CIA triad. It helps translate business needs into security actions. Key takeaway here, the enterprise information security architecture is crucial for integrating security strategically. If we don't have this enterprise security architecture, it can lead to fragmented, reactive security efforts that are both more costly and less effective. So why does it matter? What are the key benefits here? Well, it ensures security supports business goals. It helps us with security business alignment. It provides a consistent approach across the organization. It facilitates risk management by identifying gaps and overlaps in our strategy. It improves communication using common terminology and structure. And a few common approaches. There are frameworks like Sabsa and TOGAF which provide structured methods. So there are definitely some options out there that are widely adopted. The specific framework isn't as important for the exam as understanding why you'd use one, which is to systematically link business drivers to security implementation.

All right, information security management frameworks. So what are they? These provide a structured holistic approach to managing information security across the organization. They define how to set up and run your information security management system or program. We're more focused on the program. The core purpose here is to align security activities with business goals, risk appetite or compliance requirements and ensure consistent protection and continuous improvement. So the key characteristics of an information security management framework are business alignment ensuring security serves the business risk management which will guide us in our decision making around risk and they can also help us defining roles and responsibilities establishing clear accountability. And when we think about risk and assets for example remembering we need to assign accountability within our roles and responsibility the owner of an asset for example which includes information assets measurement and improvement. So the frameworks can help us in tracking effectiveness and adapting to change. Remember we need metrics that are relevant and measurable and preferably actionable. So looking at information security management frameworks, I wanted to just call out those that are most commonly mentioned in this area. So to give you one place to begin to kind of process some of those many acronyms and numbers you've seen throughout here. So we have ISO 271 which is really just a global standard. We see this everywhere. Its focus is establishing, implementing and maintaining an information security management system. It has a sister document that's ISO 272 that gives us guidance on controls. There's the NIST cyber security framework which provides guidance on improving cyber security posture with a riskbased approach. It's widely adopted. It's voluntary. It's designed for non-government agencies or entities. And then there's the NIST RMF, the risk management framework, which helps in managing security and privacy risk and integrating that into the systems development life

cycle. The NIST RMF is mandatory for the US federal agencies to whom it applies, but it's designed for government entities.

There's Cobb, which is IT governance and management aligning it with business objectives. This comes from Isaka. So it is fairly likely to be mentioned on the exam in my opinion. I've covered Cobbit from various perspectives throughout the series so far and will continue to do so.

There are industry specific frameworks like PCIDSS for credit card processors. There's HIPPA for the healthcare space and then NERK that applies to bulk electric systems. So these are your power operators. These I see as most likely are most commonly mentioned.

If you have a copy of my CISM, the last mile exam prep book, I have an appendix with a list of different standards and frameworks with a brief description and a link to additional reading or a link to the framework itself for those that are publicly available. You can get that book for 10 bucks still over on leanpub.com.

So number four, essential framework components, the building blocks of a program. So regardless of the specific framework you're using, a comprehensive security program needs components covering different areas. So think of these as the categories you need to address.

There's the technical category. This is security hardware and software, firewalls, SIM, intrusion detection and prevention, your encryption tools.

There's the operational, the day-to-day security processes like vulnerability management, patching, access reviews, monitoring, incident response, management.

So the governance strategy and oversight whether that's risk management the metrics and reporting policy approval administrative our formal documentation and structures policies standards procedures roles and responsibilities the educational and awareness activity. So training and communication efforts to build a security conscious culture to make sure that all of our employees are security aware.

Key takeaways here. A successful information security manager uses architectures like that enterprise information security architecture and the management frameworks like ISO 271 as tools. You select and adapt them to build a comprehensive riskbased security program covering all component areas, the technical, the operational, and the management that demonstrates support and protection for the organization's mission. Your job is to focus on applying these concepts strategically to building that program that aligns to the business.

All right, that's all I'm going to say about standards and frameworks. Let's tackle a practice question here to test our knowledge. An information security manager wants to develop an information security management system. What standard should they use? Is it ISO272? Is it ISO271? Or is it the NIST cyber security framework? Or perhaps PCIDSS.

So based on even what we've covered here in this section, in this installment, we could knock out the NIST cyber security framework and PCIDSS right away. So NIST CSF is really focused on optional guidance for non-government entities around security controls and PCIDSS is industry specific. So that leaves us with ISO 271 and ISO 272. These are sister or companion documents. Which one focuses on guidance for developing an information security management system? The answer is B. ISO 271. So that is the document that defines security techniques for information security management systems. It gives us the highlevel characteristics of an ISMS. The 272 option is the companion that provides guidance on controls we might implement.

That brings us to section 3A4, which is information security policies, procedures, and guidelines. We'll cover standards here as well. If you've been with me through the CISSP or Security Plus exams, you might recognize some of this material. I've added a bit to make it easier for you to consume. If this is our first time together on these topics, here we go.

So, I want to show you how these four components relate to one another in terms of their purpose and their specificity. So, we have a policy which is general management statements that come from the top down. The standard is a specific technical control or set of technical controls. The procedure would be step-by-step instructions. Then the guideline is a set of recommendations and best practices.

So if we were to categorize these, the policy explains why we're doing what we're doing. That's basically leadership giving us those general management statements. The standard tells us what we're doing to achieve goals. The procedure is how we do it. the steps. So these are generally mandatory. They're all part of the core process. The guidelines are optional. Those are recommendations and best practices to help us get the what, why, and how right and to do it better.

So let's go a bit deeper. So the security policy sets the overall vision and goals for information security. The standard translates the policy into specific technical requirements and best practices. Security procedures provide detailed instructions on how to implement the standards and security guidelines offer additional recommendations and best practices that can be adopted to further enhance our security.

Let's go a bit deeper. So security policies their function is to provide the overall highle direction and objectives for information security within the organization. It defines the why behind our security measures. These are going to be general statements and principles often very broad in their scope. So for example, the organization is committed to protecting the confidentiality, integrity and availability of its information assets. It almost sounds political in nature, doesn't it? It's very high level and official.

Then we have security standards. These define mandatory technical specifications and best practices for implementing the security policy. So these are tech specs. It provides the what and when for achieving security goals. It's going to be more detailed than policies specifying technical requirements for systems configurations or processes. So this is going to be created a bit further down the management chain taking that direction from the highle policy. For example, credit card data must be encrypted at rest in transit and in use a compliant encryption algorithm. We might see guidance from that from an industry standard like PCIDSS for example since we're talking about credit card processing.

Then there are procedures. So procedures provide step-by-step instructions on how to perform specific tasks related to security controls. It defines the how for implementing standards. It's highly detailed outlining exact actions to be taken in specific situations. So for example, procedures for incident response. Upon discovering a security incident, follow these steps. Isolate the affected system. Notify the security team. Document the incident. Obviously, I've simplified this a bit, but conceptually, I think you understand what I'm saying here.

And finally, we have security guidelines. So, a guideline offers recommendations and best practices for achieving security objectives, but they are not mandatory. They provide the could for additional security measures. They're the least specific, offering recommendations that can be adapted to specific situations. So, for example, employees are encouraged to take advantage of security awareness training programs. So, we know that if employees are security aware, it gives us a stronger, safer security culture. All right?

So, let me just put this into an analogy. Think of building a house. So the policy is the blueprint that describes the vision and overall requirements for the house. What we're looking to achieve as an end result. The standard would be the building codes and mandatory specifications. The electrical wiring must meet certain safety criteria, for example. Then the procedure. These would be the step-by-step instructions that construction teams follow to pour the foundation, for example, frame the walls, install the roof, do the plumbing. Then the guidelines are the optional interior design tips that can make the home more comfortable or efficient. You know, suggestions for energy saving light fixtures, for example. All right.

And that brings us to the end of section 3A4. Let's go through a practice question. So an IT support analyst is reviewing a security document that provides detailed information for compliance with a particular policy. What type of document are they reading? Is it a a standard, b a guideline, c a procedure, or d a framework? So we're looking for a document that provides detailed information for compliance with a particular policy. That's your key phrase there. What are they reading here? Well, we know it's not a standard and I know it's not a guideline. These are going to be a bit higher level. This says detailed information. So, I'm looking for something a bit more specific. So, frameworks can certainly offer a lot of different types of guidance. So, that's detailed in a sense. A procedure is certainly detailed. Which do you think it is here? So the answer is C. Procedure. The support analyst is reviewing a procedure which offers detailed step-by-step guidance for a controller configuration that complies with a policy. All right.

And that brings us to our fifth and final section for domain 3 part A. So in section 3A5, we're going to have a quick look at information security program metrics and talk about what makes an effective metric and how we tailor those to the organization. So you can't manage what you can't measure. Metrics are essential for assessing the efficacy of our security and identifying need for change. So the purpose is to tell you if the program is working or it's weak and if it's meeting goals. So metrics are your proof to management that we're delivering value to the business with security. They show the impact of security, justify our budget, they show the ROI, and they translate our our technical efforts into business terms that our leaders can understand. They confirm if your security controls are actually achieving what they're supposed to. It's a check on our controls to make sure they're effective. And remember, business alignment is key. Good metrics have to connect security performance directly to the organization's business objectives and risk appetite. Our leaders are thinking about core business functions. So they want to know that the money they are spending on security translates to delivering our core business functions more reliably and more securely. They're totally focused on business objectives. That's why you hear this so much in the CISM content. and we're always aligning to the organization's risk appetite.

Effective metric. So what makes a metric effective? So we've talked about this in earlier installments. We need to think about that smart framework. A metric needs to be relevant. So does it actually measure security posture, risk or control effectiveness? So we can use the smart approach here. The controls are measured with a metric that is specific, measurable, achievable, relevant and timebound. So we want metrics that are clear and unambiguous. They are quantifiable. They objectively measure some element of security efficacy. They need to be realistic to collect and analyze. There needs to be not a lot of manual effort in coming to that figure. and they need to be tied to business goals and for a defined period of collection or review. For example, with one organization I advise, we have cyber security board meetings on a quarterly basis. So, we tend to be showing them metrics on a 90-day window, showing them what happened since the last time we met. But don't measure just because you can. It needs to meet these objectives. It needs to be meaningful. If it's not meaningful, we call it a vanity metric.

So let's go beyond that smart framework and talk about the plus I had by smart there. So metrics need to be actionable. It means the metric must lead to a decision or an action. If you can't act on it, it's just data. It's not worth much is it? It should be audience specific. We want to tailor metrics to who is reading them. Executives need strategic key performance indicators. Our technical teams need operational details and they should be outcome focused. They should measure results and effectiveness, not just activity. So for example, if I were putting metrics together for process automation, uh I wouldn't say this month we automated 50 processes. I would say our automation efforts this month saved us x number of hours by automating this many processes and leads to cost savings of y. So, I would put some objective data in there that is meaningful to my leadership. And we're tracking metrics over time to see progress, decline, or emerging patterns that may indicate the need for action. And they need to be reliable and genuine. So, hard to manipulate and accurately reflecting reality. And in advanced cases, predictive would be great. Ideally, metrics can give us leading indicators of future issues. And there are different kinds of metrics. Some will be lagging, some will be leading. I'll give you a teaser there. We're going to dig into the different types of metrics a little further in domain 3, part B. But tailoring the metrics to the organization is going to be mandatory. There's no oneizefits-all. The metrics have to fit your organization's goals, risks, and environment. So, we're going to ask who needs this info? What do they need to know? When do they need it? And that's going to give us some guidance on the metrics that will make sense for this given scenario. If you can identify the who, the what, and the when, that can give you a good idea of the metrics you need to surface. So if it's an executive and they need to know the efficacy of our controls over the last 90 days, I can go in and start to choose metrics that make sense.

So the level of metrics, the strategic is the big picture alignment with the business mission, the overall risk posture, governance effectiveness. There are lots of metrics we're measuring in the organization for security. For executives, we're going to be looking at that strategic focus, the security ROI, and how we're aligning on risk appetite, for example. So, a lot of times we can tell them the why we've done something because it aligns to their risk appetite, management level or program level, performance of security processes, compliance, resource use, risk management effectiveness. So, for example, policy compliance rates, audit findings, uh, closure rate, you know, making sure that we're up to snuff on any findings we've we've stumbled across or come into through our measurement and audit functions. And then the operational or technical level, the day-to-day security tasks and controls. So, here we might be looking at patch timeliness, the the results of vulnerability scans, talking about our incident response times. So the metrics are going to vary by the audience we're dealing with, right? Looking at their level of visibility.

So we can leverage frameworks here for guidance. So frameworks like NIST 800-55, ISO274, Kobit, uh the balance scorecard we looked at earlier in the series can all provide structure and ideas. However, they don't guarantee perfect business alignment on their own. We can use them as toolkits, as guidance, not rigid rules. And our monitoring is continuous. Remember, metrics are not a one-time report. They're going to have that window of time they're looking at. We're going to be watching that all the time. They need regular tracking, analysis, and reporting on a periodic basis to be valuable for ongoing decision-making and continuous improvement. And what they tell us will depend on if we're dealing with a leading or a lagging metric. More on that in a second. But we want to maintain balance between different types of indicators like a predictive indicator and a reactive indicator or or trendbased indicator. So some of these are going to be looking into history and some projecting uh some potential outcomes in the future. And there are limitations here. So metrics show part of the picture like configuration compliance or performance thresholds. They often don't answer the more nuanced big picture questions on their own like how secure are we really is our investment in security to this point enough? Answering these questions requires broader context from risk assessments and security audits that confirm the cumulative results delivered by the individual components where they're looking at those core business services to make sure that the many layers of security we have add up to an effective cumulative result.

So I've talked a bit about leading and lagging indicators. I want to just touch briefly on what I'm talking about that we'll dig into in domain 3 part B. So we establish critical success factors for the functions within our program. There are key goal indicators, key risk indicators, and key performance indicators. So if I were to just drop a timeline on here of present, past, and future. Your key goal indicators tend to report results after the fact. Your key risk indicators predict potential roadblocks or risks that are emerging in the future. KPIs tend to report on past performance. However, some key performance indicators can forecast trends and indicators. We will dig in to these four in greater depth in domain 3 part B. So be sure to join me in a few days for that one. All right, that brings us to the end of section 3A5.

So let's test our knowledge with the question. Which of the following metrics is the best example of a leading indicator? Average time to mitigate security incidents, reduction in attacks against internetf facing firewalls. Percentage increase in patch compliance for critical servers or increase in attacks blocked by intrusion detection and prevention. So a leading indicator, something predicting the future. So average time to mitigate security incidents. I can cross that off because that's definitely a look at the past of how we did. I could also cross off increase in attacks blocked by IDPS. That simply tells me the intrusion detection and prevention is working. I mean I might see a trend in attacks there, but the number of attacks we see in a given period tends to fluctuate up and down. So not exceedingly meaningful. So we have a reduction in attacks against internetfacing firewalls or we have a percentage increase in patch compliance for critical servers. Which do you think here? The answer is C. Percentage increase for patch compliance for critical systems. So this metric is a leading indicator because it's a rough indicator of the reduction in probability of a future security incident. It's quantitative, right? A percentage increase in patch compliance. telling us we're more compliant in this period than we were in past, which is going to reduce vulnerabilities, an indicator that we're moving in a good direction. We're improving. All right, my friends, that's what I have for you for domain 3 part A. I hope you're getting value from the series. As always, if you have questions, drop them in the comments, ping me on LinkedIn. I'll see you back here in a few days for domain 3 part B. And until next time, take care and stay safe.