CISM Security Awareness, Third-Party Risk and Program Reporting

This part of CISM Domain 3, part B (Information Security Program Management), covers three ways the information security program reaches beyond its own controls: the awareness and training that change how people behave, the management of external services (suppliers, third parties and the nth parties behind them), and the metrics, communications and reports that tell leadership whether the program is working. They map to the official task statements on awareness training, on integrating security requirements into contracts with external parties, on monitoring those parties' adherence, on monitoring program metrics, and on reporting the program's activities, trends and effectiveness to senior leadership and other stakeholders.

The common thread is that the information security manager does not control the outcome directly. Staff decide whether to report a suspicious email, a provider runs the controls that protect outsourced data, and executives make the decisions a report asks for. The manager's job is to design the program so those people have the knowledge, contract terms and information they need, and to check that it is working.

Neighbouring material has its own lessons: security architecture, program resources and frameworks; policies, asset classification, control design and the design of metrics (baselines, targets, key risk indicators); and control implementation, testing and evaluation. Board accountability and risk reporting above appetite belong to governance and risk management. This lesson starts where metrics are already defined and asks how they are monitored and reported.

An information security awareness program should be designed from the organization's own risks: the risk assessment, incident and near-miss history and audit findings show which staff behaviours create the most exposure, and those behaviours set the content. So the program begins with a needs assessment of those sources. Delivery choices, tooling and targets come afterwards, because they only serve content that has already been chosen; generic material and other organizations' programs describe someone else's exposure, and the policy authorises training without saying what it must change.

Awareness, training and education are different depths. Awareness reaches everyone and aims to make secure behaviour a habit (spotting phishing, reporting incidents, handling data by its classification). Training teaches specific skills to particular roles. Education builds deeper expertise, usually for security staff. Most organizations need all three, aimed at different groups.

Role-based training is justified where a job carries a specific, high-impact risk that general awareness does not address. The test is what harm the role's own actions or access could cause, not how a group of staff happens to be organised.

When incidents cluster in one group, find the cause before choosing the response. Suppose warehouse staff keep sharing one login on handheld scanners even though they have all completed the annual course. Finished training has not changed the behaviour, so the useful question is why it persists; the answer may be a process problem (slow sign-in on a shared device during a shift change) that a better process or tool solves. A response chosen before the cause is understood tends to treat the symptom and invites a new workaround.

Awareness must be continuous: induction training before or at first access, short and frequent reinforcement through the year, and timely alerts when a new threat appears, with the standing content updated as risks change. A single annual course decays quickly and cannot react to what attackers are doing now.

• Induction before access. New starters are a common target and do not yet know how the organization handles data or reports incidents. Awareness belongs in onboarding, completed before or when system access is first granted, with acknowledgement of the acceptable use policy. The principle is simple: nobody should hold access before knowing the basic rules for using it.
• Timely, targeted alerts. When a new attack technique emerges (QR-code phishing aimed at staff who use mobile devices, for example), speed and reach matter: a short, specific message goes promptly to the people exposed, and the material is later folded into the standing course.
• Frequent short messages. Brief reminders, simulations and just-in-time prompts keep secure behaviour in mind better than one long session a year.
• Feedback into content. Incident lessons, simulation results and audit findings feed the next round of content, so the program follows the risk rather than a fixed syllabus.

Line managers reinforce the message, but the information security manager owns the program and decides when a threat justifies an alert. Keeping that decision central is what makes the response consistent across the organization.

Awareness effectiveness is measured by behaviour outcomes, tracked over time, not by course completions or quiz scores. Completion shows that training was delivered (an activity) and a quiz shows short-term knowledge; neither shows that people act differently at their desks.

Only a trend shows change. A single campaign's result is a snapshot; the trend across the year (ideally against a baseline) shows whether behaviour is moving. Measures should be read together, because they can tell different stories:

• Click rate and report rate answer different questions. The first shows how often individuals fall for a lure; the second shows how often the security team learns of one in time to act. Progress on one does not imply progress on the other, so a program can need to work on the reporting habit even when fewer people are being caught.
• More reports are usually good news. When reporting rises while harm from human error falls, people are recognising attempts that used to get through. Because a rising count can look alarming on a chart, the report to management should explain what it means.

Security requirements for an outsourced service should be defined before the provider is selected and the contract signed, because that is when they can shape the selection and become enforceable terms. After signing, the organization can only ask, and changes cost more. Outsourcing transfers the work, never the accountability: the organization remains accountable for its data and for the risk the provider creates.

Due diligence is risk-based, and providers are tiered by the sensitivity of the data they handle and the criticality of the service they provide, not by contract value. Most organizations have far more suppliers than they can assess in depth, so effort follows the tier: deep assessment (and often independent evidence) for the top tier, lighter questionnaires for the lowest. Any basis for tiering other than data and criticality spends assessment effort where the risk is not.

A common failure is to let the price or size of a deal set the tier. A free scheduling tool that will hold employees' home addresses and identity documents deserves the scrutiny of its data, not of its invoice. Two principles apply together: the tier follows the data and service, and the assessment that tier requires is finished before signing, while the organization can still set conditions or walk away. A certification helps only if its scope covers the service being bought.

Due diligence typically looks at the provider's security governance and policies, independent assurance reports and certifications (checking their scope), incident history, financial stability, location of data and processing, use of subcontractors, and its ability to meet the organization's continuity and exit requirements.

The contract is where security requirements become enforceable, so it should state what the provider must do, how the organization can verify it, and what happens to the data when the relationship ends. Obligations (service levels, indemnities, confidentiality) set duties or compensation; verification clauses provide the means to check them.

When a provider will not grant a right to audit, as large cloud providers often cannot for thousands of customers, the usual answer is to make the provider's third-party attestations part of the deal: the contract requires it to share up-to-date reports from an independent auditor that cover the service. Those give evidence before anything goes wrong, which compensation terms cannot. The organization still has to check each report's scope and period.

Breach notification needs a defined window. Where a provider processes the organization's data, the organization usually keeps the legal duty to notify regulators and affected people (under the GDPR, for example, the controller notifies the supervisory authority within 72 hours of becoming aware of a breach where feasible). Vague timing words leave the provider to decide how fast it tells you. The contract should fix a maximum notice period short enough that the organization can still investigate and meet its own deadline, and that duty stays with the organization whoever does the work.

Exit terms protect data that outlives the contract. When the relationship ends, the provider still holds the organization's data in live systems and backups. The contract should oblige the provider to hand the data back in a form the organization can load and use, by an agreed date, then erase what remains everywhere it is held, including backups, and confirm this in writing. Other clauses in the table protect the relationship while it runs; only the exit terms protect the data after it ends.

Nth-party risk is the risk from the providers' own providers (fourth parties and beyond), which may handle the organization's data or support its services without any contract with the organization. It is managed through the direct provider: knowing who the subcontractors are, being told when they change, and requiring the provider to bind them to equivalent obligations.

• Notice of changes beats a static list. A list of subcontractors at signing goes out of date. A clause requiring advance notice of new or changed subcontractors gives the organization time to assess them before they touch its data. Notice is what turns a subcontractor change into something the organization can assess rather than discover later.
• Flow-down. The provider must impose security obligations on its subcontractors at least as strong as its own, so protection does not stop at the first link.
• A notice is a cue to assess. A change notice raises two questions: can the new party protect the data, and do the rules on where the data may go and which law applies still hold? Legal or privacy colleagues help with the second. Only then does the organization accept, attach conditions or object, because its accountability for the data does not pass down the chain.

Concentration risk appears when several critical providers rely on the same fourth party, such as one data centre operator or cloud platform. Each provider may look acceptable on its own, yet all fail together if that fourth party fails, and recovery plans that assume services fail independently may not hold. Supplier mapping reveals this. Start by working out what the business would lose, and for how long, if that shared dependency went down, and give that analysis to the owners of the affected services so they can choose a treatment. Changes to suppliers or their architecture are possible treatments, decided once the impact is understood.

An independent assurance report gives evidence about a provider's controls from a party other than the provider, but only for the controls, scope and period it covers, so the information security manager must read what it includes and what it leaves out. SOC 2 reports, issued under AICPA standards by an independent service auditor on controls relevant to security, availability, processing integrity, confidentiality and privacy, are the most common example. (SOC 1 covers controls relevant to customers' financial reporting; SOC 3 is a general-use summary of a SOC 2 examination.)

Three traps follow from this. A carve-out report is silent about the carved-out layer, such as a payment processor or data centre the provider depends on; assurance for that layer has to come from somewhere else. A clean opinion still depends on the customer: the CUECs are the customer's own responsibility, so if it does not perform them the report's conclusions rest on controls nobody is running. Reports age: a Type II report covers a past period, so for the months since it ended the customer relies on a bridge letter until the next report arrives.

ISO/IEC 27001 certification is also widely used. It shows that the provider's information security management system was certified for a defined scope, so check that the certificate's scope and statement of applicability cover the service being bought.

Monitoring of external parties is proportionate to their risk tier and continues for the life of the relationship: high-tier providers get frequent, independent checks, low-tier providers lighter reviews, and significant events trigger reassessment regardless of the calendar. Monitoring depth is set by the tier, which follows data and criticality.

• Validate self-assessment. A questionnaire the provider always returns fully compliant is self-reported. Independent signals, such as an external security rating service, breach news or assurance-report exceptions, can contradict it. When they disagree, put the specific discrepancies to the provider and ask it to prove they have been dealt with. External ratings can be wrong, so stronger measures are justified only if the provider cannot back up its answer; repeating the self-assessment adds nothing independent.
• Event-triggered reassessment. A change of ownership, a move to new infrastructure, a new subcontractor, a breach or a change in the services or data supplied changes the controls the last assessment relied on. The assessment should be refreshed ahead of the change rather than on the next scheduled date; the tier itself moves only if the data or the service's criticality does.

When a provider breaks a security requirement, remediation is normally preferred to exit, and the interim risk is accepted by the business owner. The response weighs how quickly the gap can be fixed against how long and disruptive leaving would be. Where the fix is quicker than an exit, it is agreed as a remediation plan with dates and evidence that is followed until closure. Until it is fixed, the organization carries a risk, and the decision to accept it belongs to the business owner of the outsourced service and its data, who weighs it against the service's value. The information security manager supplies the analysis and follows the plan through; other functions support the relationship, but ownership of the risk stays with the business owner. Exit is the last resort, used when remediation fails or the risk is unacceptable.

Offboarding has two halves: the data and the access. Data return and certified destruction cover the first. The second is removing every logical and physical access the provider held, including accounts, VPN and support connections, keys and badges. Access that survives the end of a contract is a live exposure, not a paperwork issue: the priority is to shut it off, then find out what it was used for after the relationship ended, which tells the organization whether it has an incident to handle. Process improvements come once the exposure is closed.

Program reporting turns monitored metrics into information each stakeholder can act on: it starts from who needs to decide what, reports outcomes against objectives rather than activity, interprets the figures and states the decisions needed. Operational metrics help the teams running controls; management metrics show leadership whether the program is protecting the business. Monitoring both, and reporting each to the right audience, is part of running the program.

Plan communications from the audience. The first step is a stakeholder analysis: identify the stakeholders and the information each needs. Everything else about the reporting design follows from that analysis.

A single report written for everyone serves no audience well, because the problem is content, not presentation. Each reader needs the information that bears on the decisions they own.

Report effectiveness, not just delivery. Schedule and budget measure delivery; risk reduction against the program's objectives measures outcome. A program can hit every milestone and still miss its purpose; when that happens the report should say so plainly and propose how the plan will change. The same applies to questions about value: investment is justified by what changed in the risks it targeted and the objectives achieved, while counts of activity describe effort. Likewise, a year with no reported breaches is weak evidence: breaches are a lagging indicator and only count what was detected, so the absence may reflect weak detection rather than effective controls.

Interpret, don't just list. A page of uninterpreted metrics rarely leads to action. A useful report explains the main trends, their business significance and the decisions needed. Interpretation includes explaining why a figure moved. When a number changes because the measurement changed (for example, a metric now counts a wider population than before), the report says so, keeps the comparable series separate from what the wider scope revealed, and presents both, so leadership sees neither false alarm nor hidden exposure.

Escalate significant matters out of cycle. The reporting calendar suits routine information. Events that are new, carry potential legal, regulatory, financial or reputational impact and need a decision now, such as evidence that personal data has been exposed or a lawsuit naming a security failure, go to senior management straight away through the agreed escalation path, which exists so the right decision-makers hear quickly and consistently. Routine progress and matters leadership already knows about stay in the scheduled report.