ISSMP key terms

The decision rights and accountability structures that direct how an organization sets security strategy, allocates resources, and measures results, so security activities align with business objectives and legal obligations.

A cross-functional body of senior leaders from security, IT, legal, and business units that approves security strategy, prioritizes investments, resolves conflicts, and reviews program performance on a recurring schedule.

A documented justification for an investment stating the problem, options considered, costs, expected benefits, risks, and a recommendation, giving decision makers what they need to approve or reject funding.

The ongoing, documented effort an organization makes to identify and understand the risks it faces and to verify that controls and third parties meet agreed requirements before and during a relationship.

A process for identifying vendors and partners that handle data or deliver critical services, assessing their security posture, setting protective contract terms, and monitoring performance throughout the relationship.

A structured, recurring effort to teach employees the behaviors and policies that reduce risk, delivered through training, simulated attacks, and communications, and measured so weak areas can be corrected.

The phased process used to plan, design, build, test, deploy, and retire a system, with security activities embedded in each phase so controls are designed in rather than added later.

A table linking each stated security and functional requirement to its design element, code, and test case, proving that nothing required was dropped and that testing covers what was specified.

A group authorized to review, approve, defer, or reject proposed changes to a system or its baselines, weighing risk, testing evidence, and business impact before authorizing implementation.

An approved, documented snapshot of a system's components and settings that serves as the reference against which changes are evaluated and unauthorized drift is detected.

The practice of keeping development, test, and production systems on distinct infrastructure with controlled promotion paths, so unproven code or developer access cannot damage live operations or data.

Certification is the technical evaluation confirming a system meets its stated security requirements; accreditation is a senior official's formal decision to accept the remaining risk and authorize operation.

The layered set of documents, policy, standard, procedure, and guideline, where policy states mandatory management intent, standards set specific requirements, procedures give steps, and guidelines offer advice.

A statement of what a control is meant to achieve, expressed as an outcome, from which specific controls and test procedures are derived and against which compliance is measured.

A document listing each control in a chosen framework, marking whether it is applied or excluded and giving the justification, so auditors and management can see the scope of the compliance program.

A comparison of the controls an organization currently operates against those a chosen framework or regulation requires, producing a prioritized list of shortfalls and remediation actions.

Records, logs, screenshots, and interviews gathered to show that a control operated as described during the audit period; evidence must be sufficient, reliable, and traceable to the control tested.

A formal route for granting time-bound approval when a requirement cannot be met, recording the compensating controls, the risk owner's acceptance, and an expiration date for review.

Appetite is the amount of risk leadership is willing to accept while pursuing objectives; tolerance is the acceptable variation around a specific threshold, guiding which risks require treatment.

A living record of identified risks, each with an owner, likelihood and impact ratings, existing controls, treatment plans, and status, used to track and report risk over time.

The risk that remains after existing controls and planned treatments are applied; it must be compared with the risk appetite and formally accepted by an accountable owner.

The expected yearly cost of a risk, calculated as single loss expectancy multiplied by annualized rate of occurrence, used to compare the cost of controls with the losses they prevent.

Choosing and applying a response to a risk: mitigate by adding controls, transfer through insurance or contracts, avoid by stopping the activity, or accept and monitor it.

A structured examination of a system's components, data flows, and trust boundaries to find where an attacker could act and which controls would reduce those exposures, usually done during design.

A measurable signal, tracked against thresholds, that shows whether a risk is rising or controls are weakening, giving management early warning before losses occur.

A documented set of roles, phases, and procedures, covering preparation, detection, containment, eradication, recovery, and lessons learned, that guides the organization's reaction to a security incident.

Observable artifacts such as file hashes, IP addresses, domains, or registry keys that suggest a system has been breached, used to detect and scope intrusions.

Information about adversaries, their capabilities, and their intent, collected and analyzed from internal and external sources and tailored to the organization so defenses reflect real threats.

A publicly maintained knowledge base of adversary tactics and techniques observed in real intrusions, organized as a matrix and used to map detections, assess coverage, and prioritize defensive work.

A documented, unbroken record of who collected, handled, and stored evidence, when, and why, so the evidence stays admissible and its integrity can be defended.

A staffed function that monitors alerts, correlates them across tools, investigates suspicious activity, and drives incident response on a continuous basis.

A study that identifies critical business processes, quantifies the harm caused by their outage over time, and derives the recovery objectives that continuity and recovery plans must satisfy.

The target time within which a process or system must be restored after a disruption, set from the business impact analysis and used to size recovery capabilities.

The maximum amount of data, measured in time, that the business can afford to lose; it determines how frequently backups or replication must occur.

The longest outage a business process can endure before the harm becomes unacceptable; recovery time objectives and recovery plans must fit inside it.

Documented arrangements for keeping critical business functions running during and after a disruption, covering people, facilities, suppliers, communications, and manual workarounds.

A plan focused on restoring IT infrastructure, data, and applications at an alternate location after a major disruption, detailing teams, backups, and sequenced recovery steps that support the continuity plan.

A prearranged facility or cloud arrangement, hot, warm, or cold, where processing resumes after the primary site is lost; the type chosen depends on the recovery time objective.

Exercising continuity and recovery plans through walkthroughs, tabletop scenarios, simulations, or full failovers to verify procedures work, roles are understood, and recovery objectives are achievable.