CISM Security Policies, Asset Classification, Control Design and Metrics

This part of CISM domain 3A covers the documents, classifications, controls and measures that turn an information security strategy into a working program: the policy framework that states management's intent, the identification and classification of information assets, the design and selection of controls that treat risk, and the metrics that show whether the program is achieving its objectives. Each one depends on the one before it. Policy sets direction, classification says what deserves how much protection, control design decides how that protection is delivered, and metrics show whether it works.

The CISM view is a manager's view. The information security manager drafts and maintains the policy framework, sets up the classification process, recommends controls and defines the metrics. The manager does not personally approve the policy (senior management does), decide an asset's classification (its owner does) or audit compliance (internal audit does). Many items in this area turn on exactly that division of roles.

Three neighbouring areas are covered in their own lessons: security architecture, program resources and industry frameworks (the first part of 3A); control implementation, testing and evaluation (3B); and awareness, external parties and the communication and reporting of metrics (3B). This lesson stops at designing controls and building metrics.

A policy states management's intent, a standard sets a mandatory and specific requirement, a procedure gives the steps to carry a requirement out, and a guideline offers advice that people may follow or depart from. Together they form a hierarchy: each standard, procedure and guideline should trace back to a policy statement that authorizes it.

Policies stay high-level and technology-neutral. A good policy statement is short, mandatory in tone and durable. If a statement names a product, a tool, an algorithm or a setting, it belongs in a standard or a procedure. That is what lets the policy survive technology change: replacing an on-premises directory with a cloud identity service, or moving an application to a new database platform, changes the configuration standards and procedures that describe the systems, not the policy that states the intent. Business policies that express legal or business obligations, such as data protection or document retention, are likewise independent of where and how systems are hosted.

Only mandatory documents create noncompliance. Departing from a standard, or from a mandated procedure, is a compliance failure that needs either correction or a formal exception. Departing from a guideline is not: a guideline exists to recommend a route while leaving the choice to the reader, so following a different but equally sound approach that still meets the governing standards breaches nothing and needs no formal process. If management concludes that a practice really must be followed everywhere, it should promote it deliberately into a standard, with the approval that standards require.

Senior management or the board approves the information security policy, the information security manager prepares and maintains it, and internal audit independently checks compliance with it. The policy speaks for the whole organization, so it needs top-level authority. The IT department is one stakeholder among many, and audit must stay independent of the documents it assesses.

Standards are approved under delegated authority. Standards are mandatory but change far more often than policy, and sending every revision to the board would hold urgent changes for weeks. The usual design is delegation written into the governing documents: senior management, through the policy, empowers a named executive or a security steering committee to approve standards. Two properties must survive whatever mechanism is chosen: standards stay mandatory, and every change is authorized and recorded before it takes effect.

Policies are reviewed on a schedule and when something important changes. Periodic review (commonly annual) keeps the framework current. Events that change business objectives, risk appetite or legal obligations warrant a review before the scheduled date: a merger, a new data protection or sector law, a shift in business model such as starting to sell directly to consumers, or a change in risk appetite after a serious incident. Changes lower down are absorbed lower down: new tooling is reflected in standards and procedures, and an error in one procedure is corrected in that procedure.

Groups that operate under several legal regimes use a tiered framework. The common intent is stated once, in a group-wide policy, and the local differences that each jurisdiction's law demands are expressed further down the hierarchy, in entity- or region-level standards and procedures. The policy layer stays short, stable and consistent across the group, while the legal detail can change country by country without rewriting the group's direction.

Harmonizing two policy sets starts with evidence. When frameworks meet, for example when a joint venture or a newly acquired business brings its own documents, a gap analysis against the group framework shows where each is stronger, weaker or silent. Decisions about what to keep, adopt or retire are made from that comparison, not before it.

Information asset identification is the process of building and maintaining an inventory of the organization's information assets and assigning an owner to each, and it must come before classification. Classification asks how valuable or sensitive an asset is, and the owner is the person who answers. Without a known asset and a named owner, there is nothing to classify and nobody with the authority to do it.

The inventory should capture what the asset is, where it is held (on premises, in cloud services, with suppliers), what information it contains, which business process it supports and who owns it. Automated discovery helps find data in places people have forgotten, but an inventory also needs the ownership and business context that only people can supply. Protection requirements such as encryption and handling rules follow from classification, so they come after it.

Inventories go stale, especially with cloud services and shadow IT. Teams create cloud storage, collaboration spaces or test environments that hold copies of real data, and that data then sits outside the classification program. When information turns up outside the inventory, for example a copy of a customer database in a developer's test environment, the first job is to establish the facts: what is there, where, who owns it and what business purpose it serves. Decisions about keeping, moving or deleting it follow once the owner has classified it and the risk is understood.

Information classification assigns each information asset a sensitivity level based on the business impact if it were disclosed, altered or made unavailable, and on the legal and contractual requirements that apply to it. Its primary benefit is proportionate protection: without it, an organization either protects everything to the highest level, which is costly, or everything to the lowest, which is risky. Classification describes the information itself, not the systems that hold it or the controls already around it.

The data owner decides the classification. Classification is a business judgement about value and impact, so it belongs to the business owner of the information.

Because the decision is the owner's, any request to change a classification from someone else, such as a project team that finds the required controls slow, goes to the owner together with the security manager's view of the risk. The same applies when the security manager believes an owner has got it wrong, for example a research dataset containing health records labelled below the level its contracts require: the security manager explains the obligation to the owner, who corrects the level. Escalation to senior management is the next step only if the owner declines to act.

Good schemes have a few clearly distinct levels. Common schemes use three to five levels (for example Public, Internal, Confidential, Restricted). When there are too many, staff cannot tell neighbouring levels apart and apply them inconsistently. If people keep confusing levels, the structure is the problem, and reducing it to levels people can distinguish is the lasting fix.

Each level needs defined handling requirements. A label only creates protection when the scheme says what it requires: who may access the information, how it is stored, transmitted, printed, shared externally, retained and destroyed. A label without handling rules is decoration; the protection lives in the requirements attached to each level.

Aggregation means that combined information can be more sensitive than any of its parts, so a compilation must be classified on what it reveals as a whole. The usual rule for a document that draws on several sources is to give it the level of its most sensitive input (the high-water mark). That rule fails when the combination enables an inference that none of the parts allows on its own: a staff directory, an office floor plan and shift rosters may each be Internal, but together they tell an outsider who will be where, and when. Because classification reflects the impact of disclosure, and the impact of the combined set is higher, it can need a higher level than any input. The owner of the compiled information decides, using the same impact-based criteria.

Classification changes over the information life cycle. Sensitivity is not permanent. Merger terms are restricted until the deal is announced; a bid price is confidential until the contract is awarded; some data becomes more sensitive as it is combined or as regulation changes. If classifications are never revisited, the organization keeps paying for controls it no longer needs (overclassification) or under-protects information whose sensitivity has risen.

The fix is built into the classification itself. At the moment of classifying, the owner records when the level should be reconsidered, either a date or a defining event such as an announcement or the end of a contract, and the process reminds them when it arrives. Reclassification stays the owner's decision and is made on impact, the same criterion used to classify in the first place.

Control design starts by defining the control objective, which is a statement of what the control must achieve against a specific risk, for example preventing unauthorized changes to payroll records. Technology, ownership, operating procedures and metrics are all chosen to meet that objective. Starting from a product or a team risks a control that runs well but is aimed at the wrong thing.

Controls are selected from risk assessment results. The risk assessment for a system or process says which risks need treating, how far, and against what risk appetite. Industry frameworks (ISO/IEC 27002, NIST SP 800-53, CIS Controls and others, covered in the frameworks lesson) are a catalogue of candidate controls, but a catalogue does not know this system's threats, data or appetite. A framework helps you find and describe controls; the risk assessment chooses them.

Solution-first requests get tied back to a risk. When someone arrives wanting a particular product, for example a business unit head back from a conference, the security manager's first question is what problem it would solve: which risk it treats and which control objective it serves. A real objective then shapes the evaluation, the comparison with alternatives and the business case; without one, the purchase may not be justified at all.

The best design meets the objective without breaking the business. Requirements often pull in two directions: stop a risk, but keep a legitimate business activity working. The right design satisfies both stated constraints. If the objective is to prevent something, a control that only detects or warns does not meet it on its own, however useful it is; if an activity must keep working, a control that stops it outright fails the business requirement. Designs that apply the preventive control selectively, according to the risk, often meet both: requiring step-up authentication for payments above a limit protects high-value transfers while routine payments flow normally. Security requirements are also built into organizational processes (procurement, project and change management, system development) so controls are designed in rather than added later.

Controls are classified by what they do: preventive controls stop an event, detective controls identify that it has happened or is happening, and corrective controls restore the system or limit the damage afterwards. Deterrent controls discourage the attempt, and compensating controls stand in for a primary control that cannot be applied. A single tool can perform more than one function; classify each function separately.

Defense in depth layers independent controls, and the layers should include different control types. Controls that all work the same way share the same failure mode: once an attacker gets past one preventive layer, more preventive layers built on the same idea may fall too, and nothing notices. A layered design prevents what it can, detects quickly what gets through, and can correct by restoring. For online payment fraud, for example, that could mean strong authentication and transaction limits (prevent), fraud-scoring alerts (detect) and a process to reverse and recover fraudulent payments (correct).

Every key preventive control needs a timely detective control. A preventive control can fail silently: a misconfigured access rule grants more than intended and nothing says so. Prompt assurance comes from a detective control that watches for the very events the preventive control exists to stop. For an access rule protecting a payments database, that is alerting on access by accounts outside the authorized group, so a failure is noticed in hours rather than at the next review.

Compensating controls must target the risk the missing control left open. When segregation of duties is not feasible, for example in a small finance team where one clerk both enters and releases supplier payments, the open risk is that one person can push through an unauthorized transaction. Effective compensating controls review before and monitor after: a supervisor checking payments against approved invoices, and a periodic reconciliation by someone outside the team. A control aimed at a different risk is not compensating, however good it is, and the chosen option still has to respect any stated constraint such as cost.

A control is cost-justified when the reduction in expected loss it delivers is greater than what it costs, measured over the same period. In quantitative terms, the benefit is the annual loss expectancy (ALE) before the control minus the ALE after it, and that benefit is compared with the control's annual cost.

Worked example: a risk has an ALE of 120,000. A control would reduce it to 90,000 and costs 50,000 a year. The benefit is 120,000 − 90,000 = 30,000 a year, which is less than the 50,000 cost, so on cost alone the control loses 20,000 a year. The comparison is always loss avoided against cost, in the same units and over the same period; the size of the total exposure is not the benefit.

Compliance and non-financial drivers can override the arithmetic. A legal, regulatory or contractual requirement can make a control mandatory regardless of its cost-benefit result. Reputational impact, safety and customer trust are also legitimate drivers that a pure ALE figure may not capture, and should be stated explicitly in the business case rather than hidden in inflated numbers.

Compare controls on total cost of ownership, not purchase price. When two controls would both bring a risk within appetite, effectiveness no longer separates them; cost does. Total cost of ownership includes implementation, licences, the people and hours needed to operate the control, maintenance and eventual replacement. A control that needs an analyst's attention every day carries that labour cost for every year it runs, which can outweigh a large difference in upfront price.

Information security program metrics are measures designed to show whether the program is making progress toward defined business and security objectives, so the first test of any metric is relevance: what decision or objective does it inform? A metric that informs no objective is noise, however easy it is to collect or present.

Management metrics differ from operational metrics. Operational (activity) metrics describe what controls and teams are doing: patches applied this week, alerts triaged, scans completed. They help the people running those controls. Management (program effectiveness) metrics tell executives whether the program is protecting the business, such as the share of critical systems recovered within their recovery time objective in tests, or the proportion of high risks treated within agreed timescales. Budgets and activity counts describe effort, not outcomes.

A metric needs a baseline and a target to mean anything. A figure on its own cannot answer "is this acceptable?". The target, derived from risk appetite, says what level is acceptable; the baseline shows the starting point and therefore whether things are improving. External figures give context, but acceptable risk is set internally, and only the organization's own starting point shows its progress. Timing matters: capture the baseline before a change takes effect, such as measuring current excess privileges before a new access-review process starts, because once the change happens the "before" state is gone.

Key risk indicators warn that exposure is rising. KPIs show how well a process performs (request volumes, fulfilment times, training completion). KRIs are leading signals of risk, such as the number of critical systems running unsupported software or critical vulnerabilities open past their deadline. A KRI needs a threshold, set from risk appetite, at which rising exposure is escalated for action. Without one it is just a trend line, and nobody knows when it demands a decision.

Measure as precisely as the decision needs. These attributes trade off, and precision is worth paying for only up to the point where it changes a decision. If measuring something exactly would cost more than the losses the risk could cause, a cheaper, approximate measure that still supports the decision, delivered as often as management needs it, is the better metric. How metrics are then communicated and reported to stakeholders is covered in the program reporting lesson.