Skip to main content
Control Institute
Category: Incident Management

Precursors and Indicators

Also known as: Precursor, Indicator, Incident Precursors and Indicators
Simply put

Precursors and indicators are the warning signs that security teams watch for when detecting potential security incidents. A precursor is a sign that an attack may be coming or being prepared, while an indicator is evidence that an incident is already occurring or has already happened. Together they help responders decide when and how to react to a possible incident.

Formal definition

In incident response practice, a precursor is a sign that an attacker may be preparing to cause an incident, signaling a potential future event, whereas an indicator is an observable artifact or piece of evidence suggesting that an incident is currently occurring or has already occurred. The distinction is temporal: precursors point to potential future incidents, while indicators reflect ongoing or past activity. Detection depends on the monitoring capabilities, logging, and alerting in place, so the specific signals treated as precursors or indicators vary by environment and scope. In a SOC 2 examination these concepts typically support controls evaluated under the Security (Common Criteria) category related to incident detection and response, and in an ISO/IEC 27001 ISMS they inform information security event and incident management processes; the exact controls and evidence assessed depend on scope and the applicable criteria or Statement of Applicability.

Why it matters

The distinction between precursors and indicators shapes how a security team allocates attention across the timeline of a potential incident. A precursor gives responders a chance to act before harm occurs, allowing hardening, heightened monitoring, or preventive measures. An indicator, by contrast, signals that activity is already underway or has already taken place, shifting the emphasis toward containment, eradication, and recovery. Recognizing which type of signal is present helps teams calibrate an appropriate and timely response rather than treating every alert identically.

For organizations pursuing SOC 2 or ISO/IEC 27001 outcomes, the ability to distinguish and act on these warning signs underpins the credibility of incident detection and response capabilities. A SOC 2 examination attests only to the controls and the period covered and does not guarantee freedom from breaches; demonstrating that precursors and indicators are defined, monitored, and acted upon provides evidence that detection controls were suitably designed and, in a Type II engagement, operating effectively over the review period. Similarly, an ISO 27001 ISMS treats these concepts as inputs to information security event and incident management processes, but only within the defined scope of the ISMS.

Because detection depends on the monitoring, logging, and alerting actually in place, the practical value of these concepts is bounded by an organization's visibility. Signals that go uncaptured cannot be classified as either precursors or indicators, so gaps in instrumentation directly limit an incident response program's reach regardless of how well the terminology is understood.

Who it's relevant to

Security engineers and SOC analysts
Those responsible for monitoring, detection, and triage rely on the precursor-versus-indicator distinction to prioritize alerts and choose between preventive action and active containment. Their ability to recognize these signals depends directly on the logging, alerting, and monitoring capabilities deployed in their environment.
Incident response teams
Responders use precursors to prepare for or forestall potential incidents and indicators to confirm and scope activity that is underway or has already occurred. This classification helps determine the timing and nature of the response actions taken.
Compliance managers and GRC professionals
For those preparing for a SOC 2 examination or maintaining an ISO/IEC 27001 ISMS, defining and documenting how precursors and indicators are detected and handled supports the incident detection and response controls that auditors and certification bodies assess. The specific controls and evidence in scope depend on the applicable criteria or the Statement of Applicability.
Auditors and assessors
Practitioners performing a SOC 2 attestation or an ISO 27001 certification audit may examine how an organization identifies and acts on these warning signs as part of evaluating incident management processes, though what is reviewed depends on the defined scope and period covered.

Inside Precursors and Indicators

Precursors
Signs or observable conditions suggesting that a security incident may occur in the future. Precursors are forward-looking indicators of potential threat activity, though in practice they are relatively uncommon and, when present, may still not reliably predict an actual incident.
Indicators
Signs that an incident may already be occurring or has occurred, drawn from sources such as log entries, alerts, and anomalous system or user behavior. Indicators are typically far more numerous than precursors and form the primary basis for incident detection.
Detection sources
The systems and inputs from which precursors and indicators are gathered, which may include intrusion detection and prevention systems, SIEM platforms, antivirus and endpoint tools, log analyzers, and reports from personnel. The specific sources depend on the environment and monitoring scope.
Analysis and correlation
The process of validating, prioritizing, and correlating signals to distinguish genuine incident evidence from false positives or benign activity. The volume of indicators typically requires triage, and interpretation depends on context and analyst judgment rather than any single fixed rule.
Relationship to incident response
Precursors and indicators feed the detection and analysis phase of an incident response process, supporting decisions about whether to escalate, contain, or investigate. They inform, but do not by themselves determine, the response actions taken.

Common questions

Answers to the questions practitioners most commonly ask about Precursors and Indicators.

Is a SOC 2 report a certification that proves my controls are compliant?
No. SOC 2 is an attestation examination performed by a licensed CPA firm under the AICPA SSAE 18 standard, and it results in a report rather than a certificate. The report expresses the practitioner's opinion on the controls and, for a Type II, their operating effectiveness over the defined review period. It attests only to the controls and period covered and does not certify your organization or guarantee freedom from breaches. If you need a certification against a management system standard, that is the domain of ISO/IEC 27001, which is issued by an accredited certification body.
Are the SOC 2 Trust Services Criteria the same as ISO 27001 Annex A controls?
No, they are distinct constructs from separate frameworks. The Trust Services Criteria organize SOC 2 into categories, of which Security (the Common Criteria) is the only required one, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on scope. ISO 27001 Annex A lists reference controls selected via a Statement of Applicability and informed by risk assessment, and it sits alongside the certifiable ISMS requirements in clauses 4 through 10. Mapping between the two is possible but partial, and satisfying one does not automatically satisfy the other.
How do we decide which Trust Services Criteria categories to include in a SOC 2 engagement?
Selection depends on scope and the commitments you make to customers. Security (the Common Criteria) is required in every SOC 2 engagement, and the remaining categories are added when they are relevant to the services you provide. In most engagements, organizations discuss the intended use of the report and stakeholder expectations with their CPA firm before finalizing the categories. Because the appropriate mix varies by scope and applicable criteria, there is no single universal combination.
Should we pursue a SOC 2 Type I or a Type II first?
It depends on your objectives and readiness. A Type I assesses the suitability of design of controls at a point in time, which can be useful when controls are newly implemented, while a Type II assesses both design and operating effectiveness over a defined review period. Some organizations begin with a Type I to demonstrate design and then move to a Type II, but this sequencing is a scoping decision rather than a mandatory path. The Type II review period length varies and is set through scoping discussions with your CPA firm.
How do we set the scope of an ISO 27001 ISMS for certification?
Scope definition is part of the ISMS requirements in clauses 4 through 10 and typically considers the organizational context, interested parties, and the boundaries of the information you intend to protect. The Statement of Applicability then documents which Annex A reference controls are included or excluded, informed by your risk assessment. Keep in mind that an ISO 27001 certificate covers only the defined scope of the ISMS, so the scope statement determines exactly what the certification applies to.
If we already have one framework in place, can we reuse that work for the other?
Often partially, but not automatically. Mapping between SOC 2 and ISO 27001 is possible, and evidence or controls addressing common areas may support both efforts, depending on scope and the applicable criteria. However, the frameworks differ in structure and outcome, so satisfying one does not satisfy the other. In most cases you would still need the ISO 27001 ISMS requirements and Statement of Applicability for certification, and a separate CPA examination for a SOC 2 report.

Common misconceptions

Precursors and indicators are interchangeable terms.
They are distinct: precursors point to a possible future incident, while indicators point to an incident that may be occurring or has already occurred. Precursors are typically far less common than indicators, and conflating the two can distort how signals are interpreted and prioritized.
A detected indicator always confirms a genuine security incident.
Indicators frequently include false positives and benign activity. They require validation, correlation, and analyst judgment before an incident is confirmed, and the outcome depends on context rather than the presence of a single signal.
Monitoring for precursors and indicators satisfies a compliance framework's requirements on its own.
Detection activity is only one element of a broader control environment. In a SOC 2 examination, controls and their operation over the covered period are what a CPA firm attests to, and detection alone does not guarantee freedom from breaches; in an ISO 27001 ISMS, detection supports but does not replace the risk-based selection and operation of controls within the defined scope.

Best practices

Maintain and document the range of detection sources feeding your monitoring, since coverage varies by environment and gaps in sources translate directly into missed indicators.
Establish a triage and prioritization process to manage the typically high volume of indicators and reduce time spent on false positives, applying analyst judgment and correlation rather than treating each signal in isolation.
Clearly distinguish precursors from indicators in your procedures and tooling so that potential-future signals and in-progress or historical signals are handled and escalated appropriately.
Correlate signals across multiple sources before confirming an incident, recognizing that a single indicator is rarely sufficient to establish that an incident has occurred.
Retain records of detection, analysis, and escalation decisions to support the demonstration of operating effectiveness that a SOC 2 Type II examination assesses over its review period and to provide evidence within an ISO 27001 ISMS.
Periodically review and tune detection rules and thresholds against observed activity, since appropriate configurations depend on scope and context and drift over time.