Category: Risk Assessment and Treatment

Threat

Also known as: Security Threat, Cyber Threat

Simply put

A threat is any circumstance or event that has the potential to cause harm to an organization's operations, assets, or people. In a security context, threats can come from outside attackers or from insiders who misuse their authorized access. A threat represents the possibility of harm, which is distinct from an actual incident or breach having occurred.

Formal definition

In information security risk management, a threat is any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations. Threats may be external or internal; an insider threat, for example, is the potential for an insider to use their authorized access or understanding of an organization to cause harm. Threats are typically assessed against vulnerabilities and potential impact during risk assessment activities, which inform control selection and treatment decisions. Managing threats involves detecting cyber threats, preventing attacks, and responding to security events. A threat denotes the potential for harm rather than a realized event, and identifying a threat does not by itself indicate that a control has failed or that an incident has occurred.

Why it matters

Understanding threats is foundational to both SOC 2 examinations and ISO 27001 certification because risk-based control selection begins with identifying what could cause harm. A threat represents the potential for adverse impact to organizational operations, assets, individuals, or other organizations, and distinguishing this potential from a realized incident is critical. Identifying a threat does not by itself mean a control has failed or that a breach has occurred; it simply informs the organization about where harm could originate so that vulnerabilities and potential impact can be assessed.

In most engagements, threats drive the risk assessment activities that shape which controls an organization implements and how those controls are tested. Under ISO 27001, the ISMS requirements in clauses 4 through 10 call for risk assessment, and the results inform which Annex A reference controls are selected through the Statement of Applicability. Under SOC 2, the Security category (the Common Criteria) addresses risk identification and management as part of the criteria a CPA firm evaluates. In both cases, a clear understanding of the threat landscape helps ensure that control selection is defensible and proportionate rather than arbitrary.

Threats can originate externally from attackers or internally from insiders who misuse their authorized access or understanding of the organization to cause harm. Because threats represent possibilities rather than certainties, managing them is an ongoing process of detection, prevention, and response rather than a one-time exercise. Neither a SOC 2 report nor an ISO 27001 certificate guarantees freedom from threats being realized; each attests only to the controls and scope covered, depending on the engagement.

Who it's relevant to

Compliance and GRC Managers

Compliance and GRC professionals rely on a clear definition of threats to structure risk assessments that support both SOC 2 examinations and ISO 27001 certification. Identifying threats helps justify why particular controls were selected and, under ISO 27001, informs the Statement of Applicability and the treatment of risk. Framing threats as potential rather than realized harm helps avoid conflating risk identification with actual control failures.

Auditors and CPA Firms

Auditors performing a SOC 2 examination under the AICPA SSAE 18 standard evaluate whether an organization has identified and addressed relevant threats as part of the Security Common Criteria. Understanding threats as potential adverse events, distinct from incidents, allows auditors to assess whether risk identification and management activities are suitably designed and, in a Type II engagement, operating effectively over the defined review period.

Security Engineers

Security engineers translate identified threats into detection, prevention, and response capabilities. Because threats can be external or internal, engineers typically design controls that address both attacker-driven scenarios and insider threats where authorized access could be misused. Their work provides much of the evidence that supports risk-based control selection during audit and certification activities.

Certification Body Assessors

Assessors from an accredited certification body reviewing an ISMS against ISO 27001 examine how the organization identifies threats and feeds that analysis into the risk assessment required by clauses 4 through 10. The threat picture informs which Annex A reference controls the organization deems applicable, keeping in mind that the certificate covers only the defined scope of the ISMS.

Inside Threat

Threat source (actor)

The origin of a potential adverse event, which may be human (malicious insiders, external attackers, negligent users), environmental (fire, flood, power loss), or systemic (hardware failure, software defects). Identifying the source informs how a threat is assessed during risk analysis.

Threat event

The specific action or occurrence through which a threat could manifest, such as unauthorized access, data exfiltration, service disruption, or accidental disclosure. In risk assessment, threat events are typically paired with vulnerabilities they might exploit.

Relationship to vulnerability and risk

A threat represents the potential for harm; a vulnerability is a weakness that a threat could exploit; and risk generally reflects the combination of a threat exploiting a vulnerability together with the resulting impact and likelihood. These are distinct but interrelated concepts and should not be used interchangeably.

Role in ISO/IEC 27001 risk assessment

Within an ISMS, threats are identified and evaluated as part of the risk assessment process required by clauses 4 through 10. The outcome informs which Annex A reference controls are selected and documented in the Statement of Applicability, with selection depending on scope and risk decisions rather than a fixed list.

Role in SOC 2 control design

In a SOC 2 examination, an organization's consideration of threats typically underlies the design of controls mapped to the Trust Services Criteria, where Security (the Common Criteria) is required and Availability, Processing Integrity, Confidentiality, and Privacy are optional depending on scope. A CPA firm assesses the suitability of design (Type I) and, over a review period, operating effectiveness (Type II).

Common questions

Answers to the questions practitioners most commonly ask about Threat.

Is a threat the same thing as a vulnerability?

No. A threat is a potential cause of an unwanted incident, while a vulnerability is a weakness that a threat could exploit. In most risk assessments, the two are considered together: a threat becomes relevant to your risk only when there is a corresponding vulnerability it can act upon. Treating them as interchangeable can lead to gaps in how risk is identified and treated.

Does identifying a threat mean a control is mandatory to address it?

Not necessarily. Identifying a threat informs the risk assessment, but whether and how it is treated depends on the assessed risk level and your organization's risk acceptance decisions. In most engagements, threats are prioritized by likelihood and impact, and treatment options may include mitigation, acceptance, transfer, or avoidance. Neither SOC 2 nor ISO 27001 dictates a single mandatory control for a given threat; the response depends on scope, risk appetite, and applicable criteria.

How does threat identification fit into an ISO 27001 ISMS?

Threat identification typically supports the risk assessment process required under the ISMS requirements in clauses 4 through 10. Threats identified during risk assessment help inform which Annex A reference controls are selected and documented in the Statement of Applicability. The specific method for identifying and analyzing threats is generally left to the organization, provided the process is consistent and repeatable.

How are threats considered in a SOC 2 examination?

In a SOC 2 examination, threats are relevant to how an organization designs and operates controls against the applicable Trust Services Criteria, beginning with the Security (Common Criteria) category. The examination assesses whether controls are suitably designed, and for a Type II, whether they operated effectively over the review period. It attests only to the controls and period covered and does not guarantee freedom from threats materializing into incidents.

How often should an organization reassess its threats?

Reassessment frequency depends on scope, risk profile, and organizational change rather than a fixed universal rule. In most programs, threats are reviewed periodically and also when significant changes occur, such as new systems, changed business processes, or emerging attack techniques. Documenting the cadence and triggers for reassessment helps demonstrate a consistent process to both auditors and certification bodies.

Should threats be documented differently for SOC 2 versus ISO 27001?

The underlying threat information can often be shared, but the documentation is typically framed to fit each framework's structure. For ISO 27001, threats generally feed the risk assessment and Statement of Applicability tied to the ISMS requirements and Annex A reference controls. For SOC 2, threats inform controls mapped to the applicable Trust Services Criteria. Mapping between the two is possible but partial, so addressing a threat in one framework does not automatically satisfy the other.

Common misconceptions

A threat and a risk are the same thing.

A threat is the potential for an adverse event, while risk generally reflects the combination of a threat exploiting a vulnerability along with likelihood and impact. Treating them as identical can distort risk assessment outputs and control selection.

Identifying threats and passing a SOC 2 examination or achieving ISO 27001 certification guarantees the organization will not be breached.

A SOC 2 report attests only to the controls and period covered and does not guarantee freedom from breaches, and an ISO 27001 certificate covers only the defined scope of the ISMS. Threat identification supports risk management but cannot eliminate the possibility of an incident.

Because both frameworks address threats, satisfying one automatically satisfies the other.

Mapping between SOC 2 and ISO 27001 is possible but partial. The frameworks differ in structure and outcome, SOC 2 is an attestation examination resulting in a report, while ISO 27001 is a certification against a management system standard, so addressing threats under one does not automatically meet the other's requirements.

Best practices

Maintain a clear distinction between threats, vulnerabilities, and risks in documentation so that risk assessments and control rationales remain precise and defensible during an audit or certification.

Identify threat sources across human, environmental, and systemic categories rather than focusing solely on external attackers, since scope and context determine which threats are most relevant.

Tie identified threats to the ISO 27001 risk assessment process and use the results to inform Annex A control selection documented in the Statement of Applicability, specifying the standard version when referencing control themes or counts.

For SOC 2 engagements, ensure that threat considerations are reflected in controls mapped to the applicable Trust Services Criteria, remembering that Security is required and other categories are selected based on scope.

Document the boundaries of any threat analysis, noting that a SOC 2 report covers only the controls and period examined and an ISO 27001 certificate covers only the defined ISMS scope.

Revisit and update threat identification periodically as scope, systems, and the threat landscape change, rather than treating it as a one-time exercise.