BCS CISMP key terms

A documented set of policies, processes and responsibilities an organisation uses to govern information security, planned and reviewed as a whole so that controls stay aligned with business objectives and legal duties.

Confidentiality, integrity and availability: the three properties used to describe what protection information needs. Most controls exist to preserve one or more of them, and risk assessments usually judge impact against each.

Any data, system, service or physical item that has value to the organisation and therefore needs protection. Assets are identified and given owners so that risk decisions and controls can be attached to something concrete.

The named person accountable for a specific information asset, including classifying it, approving access and accepting residual risk. Ownership is an accountability role and is normally separate from the day-to-day custodian who operates the controls.

Assigning labels such as public, internal, confidential or restricted to information so that handling rules, access decisions and protection levels can be applied consistently and proportionately across the organisation.

A rule set describing how staff may use organisational systems, devices and data, including what is prohibited and what monitoring occurs. It converts expected behaviour into a disciplinary and contractual reference point.

Planned activity that gives staff the knowledge and habits to recognise threats and follow policy, such as phishing reporting and safe data handling. It reduces human-error risk and supports the effectiveness of technical controls.

Splitting sensitive tasks so that no single person can both commit and conceal an error or fraud, for example separating payment approval from payment execution. It is a preventive administrative control against insider and process risk.

The chance that a threat will exploit a vulnerability and cause harm to information or the organisation, usually expressed as a combination of likelihood and business impact. It is assessed, treated and then formally accepted or avoided.

Any circumstance or actor with the potential to cause harm, such as a criminal group, malware, an insider, fire or a supplier failure. Threats are not controlled directly; exposure is reduced by addressing vulnerabilities and impact.

A weakness in a process, configuration, code or physical arrangement that a threat could exploit. Vulnerabilities are the part of risk the organisation can usually fix most directly through patching, design change or training.

An estimate of how probable it is that a threat will act on a vulnerability within a given period, informed by historical incidents, threat intelligence and control effectiveness. It forms one half of most risk-scoring methods.

The severity of harm if a risk materialises, measured in financial loss, regulatory penalty, operational disruption, harm to people or reputational damage. Impact is judged from a business perspective, not only a technical one.

The risk that remains after planned or existing controls have been applied. It must be compared with the organisation's risk appetite and formally accepted by an accountable manager, not assumed away.

The amount and type of risk senior management is willing to accept in pursuit of objectives, expressed as thresholds or statements. It gives risk owners a benchmark for judging whether residual risk is tolerable.

Choosing and applying a response to assessed risk: mitigate with controls, transfer such as insurance, avoid the activity, or accept and monitor. Each option has cost and side effects that should be weighed against the risk.

A living record of identified risks, each with an owner, assessed likelihood and impact, existing controls, planned treatment and review date. It provides the audit trail that shows risk management is actually operating.

The person with authority and accountability for managing a particular risk, including approving treatment and accepting residual exposure within delegated limits. Ownership should sit where the business consequence is felt.

Judging risk using descriptive scales such as low, medium and high, often through structured workshops. It is fast and usable across many risks but depends on consistent interpretation of the scale definitions.

Expressing risk in numeric terms, commonly money, using estimates such as annualised loss expectancy derived from asset value, exposure factor and frequency. It supports cost-benefit decisions but relies on data quality and assumptions.

The international standard specifying requirements for establishing, operating, monitoring and improving an ISMS. Organisations can be independently certified against it, which is why it appears in supplier contracts and tender requirements.

A document listing the controls selected from the reference control set, with justification for inclusion and for any exclusions. It links the risk assessment results to the controls actually implemented in the ISMS.

The recurring cycle of measuring performance, finding weaknesses and making changes so the management system gets better over time, often described using plan-do-check-act. It is a requirement of certified management systems, not an optional extra.

A high-level management statement of intent and direction for information security, from which lower-level standards, procedures and guidelines are derived. It carries management commitment and sets the authority for enforcement.

Layering independent controls so that failure of one does not expose the asset completely, for example combining access control, encryption and monitoring. Layers should be diverse enough that a single weakness does not defeat them all.

Any safeguard or countermeasure that modifies risk, whether preventive, detective, corrective or deterrent, and whether technical, administrative or physical. Controls are selected because they address a specific assessed risk.

Giving users, services and processes only the access needed for their task, for the shortest time necessary. It limits the damage an accident, compromised account or malicious insider can cause.

Access rights that can change systems, data or security settings, such as administrator accounts. Because misuse is so damaging, such access is tightly restricted, separately logged and reviewed more often than ordinary user access.

Authentication that requires evidence from two or more different categories, such as a password plus a code from a device or a fingerprint. It reduces the value of stolen passwords, especially for remote and privileged access.

Transforming data using a cryptographic key so that only holders of the right key can read it. It protects confidentiality in transit and at rest, and supports availability of trust, but key management must be designed or it fails.

A controlled process for identifying, testing, deploying and verifying software fixes for known vulnerabilities. Delays create exploitable windows, so prioritisation is usually driven by severity and exposure.

Automated probing of systems to find known weaknesses, missing patches and misconfigurations. Results feed the risk process and remediation work; scanning finds candidates and does not by itself prove exploitability.

Authorised, simulated attack against agreed targets to demonstrate how far real weaknesses can be chained together. It complements scanning by showing business-relevant exploit paths, and needs clear scope and rules of engagement.

Recording security-relevant events with enough detail to reconstruct who did what and when, stored so that it cannot be quietly altered. Logs support detection, investigation and evidence, but must respect privacy and retention rules.

A social-engineering attack that impersonates a trusted party by email, message or site to trick a person into revealing credentials or running malicious content. Technical filtering and user reporting both reduce its success.

An event, or series of events, that actually or potentially threatens information security or breaches policy. Incidents are logged, classified and managed through a defined process so that response is consistent rather than improvised.

Documented roles, escalation routes, communication lines and steps for detecting, containing, eradicating and recovering from security incidents. It is tested through exercises so that people know what to do under pressure.

A structured review after an incident or exercise that identifies root causes and improvement actions, with owners and deadlines. Without it, organisations tend to repeat the same failures and lose the value of the experience.

The analysis that identifies critical business activities and estimates how disruption affects them over time, producing recovery priorities and targets. Its outputs drive continuity strategy rather than being an academic exercise.

The maximum acceptable time to restore a service or activity after disruption, set from business impact rather than technical convenience. It drives backup design, redundancy and the cost of the continuity solution.

The maximum acceptable amount of data loss measured in time, indicating how recent a recovery copy must be. It determines backup frequency and replication design, and differs from how quickly service must return.

Documented arrangements for keeping or restoring critical activities during and after a disruption, covering people, premises, suppliers and systems. It is validated by testing and kept current as the organisation changes.

The technical and logistical plan for restoring IT systems, data and infrastructure after a major failure, aligned to recovery targets. It is one part of continuity, focused on technology rather than the whole business.