RS.MA-02 incident triage: requirements and evidence

What RS.MA-02 incident triage requires in plain terms

An alert from the SIEM, an EDR detection or a message from an employee arrives, and someone has to decide two things quickly: is this a real cybersecurity event that needs a response, and how urgent is it? RS.MA-02 is the Subcategory that covers that decision. It sits in the Incident Management (RS.MA) Category of the RESPOND Function in NIST CSF 2.0, and its outcome is that incident reports are triaged and validated. In practice, the organization owns this step: it needs a named triage role, a documented intake path and criteria the on-duty analyst can apply without waiting for approval. NIST gives two Implementation Examples. The first is a preliminary review that confirms a report is cybersecurity-related and needs a response. The second is applying criteria to estimate severity.

The work is hard for three reasons. Report volume can bury the few alerts that matter. Many reports are vague, such as a user saying a system "feels slow", and the analyst must gather enough facts to classify them without a full investigation. And severity criteria often exist in a policy document but are not applied the same way from shift to shift, so two analysts can rank the same event differently. Ask your team to show, for a sample of recent reports, which criteria were used, who decided and when the decision was recorded. If those answers vary, the gap is in the procedure, not the tooling.

NIST's CSF 1.1 to CSF 2.0 Core Transition Changes spreadsheet records that RS.MA-02 absorbs part or all of CSF 1.1 RS.AN-1 and RS.AN-2, so organizations that mapped their earlier analysis practices should check that the triage and severity steps moved over completely. Confirm the current wording and any changes with the NIST spreadsheet itself rather than relying on secondhand summaries. Triage records also feed later Subcategories, including categorization and escalation, so the fields you capture at this stage should match what those steps need.

Which alert sources, teams and third parties RS.MA-02 triage covers

Triage under RS.MA-02 starts wherever a report enters the organization, so the work depends on which channels feed the queue, who looks at each item and which parties hand over alerts. The cards below cover the intake channels, the roles that triage and validate, the third parties whose alerts share the queue, and the scoping decisions that change how much work triage involves.

SIEM and EDR alert feeds

Security information and event management and endpoint detection tools generate most automated alerts. Triage has to decide which rules and sources feed the queue, because a noisy rule set floods analysts while a missing log source leaves whole systems outside validation. Check which detections create tickets automatically, which need a human to promote them, and whether each alert carries enough context to judge whether it is cybersecurity-related and needs a response.

Help desk and staff reports

Users often notice a problem first: a suspicious login prompt, a file that will not open, a payment request that looks wrong. These reports usually arrive through the help desk or a reporting mailbox and may describe symptoms rather than security events. Triage should define how a help desk ticket is routed to security, what questions the first responder asks, and how the reporter is told the outcome.

External notices and customer reports

Vendors, national computer emergency teams, threat intelligence feeds, researchers and customers can all report possible compromises. These notices often arrive without internal logs, so validation means confirming whether the described activity touches your assets. Record who may submit external notices, which mailbox or portal they use, and how long a notice waits before someone checks it against your inventory.

Managed detection and response providers

When a managed detection provider monitors your environment, its alerts land in the same queue as your own. Confirm which provider alerts require internal validation before action, which are closed by the provider, and how severity is communicated. Contracts and runbooks should state the handoff, the response times expected from each party, and who holds the final decision that an event is an incident.

Scope of systems and data sources

Triage can only validate events from systems the organization has defined as in scope. Decide which business systems, cloud accounts, operational technology networks, SaaS tenants and third-party hosted services produce logs that feed triage, and which are excluded. Document the scope in the incident response plan so that an analyst can tell whether a silent system is clean or simply unmonitored.

In-house or outsourced triage and shift handoffs

Triage may be run by internal analysts, by a provider, or by both in a split arrangement. Each choice changes who holds the validation decision and how quickly it is made. Where triage spans shifts, define the handover record, the open-item list and the rule for which shift owns an alert that is still under review at the change of duty. Ask any provider to show its shift handover procedure before signing.

How to build RS.MA-02 triage and validation step by step

This sequence turns a stream of incoming reports into validated, severity-rated records that the incident team can act on, with a written output at each step so an assessor can trace how every report was handled.

Define what counts as a cybersecurity report
Start by writing a scope statement that says which events enter the incident process: suspected unauthorized access, malware, data exposure, service disruption from an attack, and reports from staff, customers, suppliers or monitoring tools. Name the owner who approves the definition, usually the CISO or head of security operations, and list the report sources you expect. The output is a short written definition that separates cybersecurity-related reports from IT faults, fraud reports and privacy requests that go to other teams, with a handoff rule for each. The step is done when the owner has signed off and every intake channel is named in the document.
Write the preliminary review checklist
Build a checklist the triager completes before any report is escalated. It should ask whether the report describes a security event, whether there is evidence (logs, screenshots, indicators), whether the affected system or data can be identified, whether the activity is ongoing, and whether a response is needed or the report can be closed with a reason. This is the practical core of the NIST Implementation Examples for RS.MA-02, which describe a preliminary review confirming a report is cybersecurity-related and needs a response. The output is a triage runbook section with yes or no questions, expected evidence and a required closure note. Test it by having two people apply it to the same report and compare results.
Set severity criteria with named levels
Define named severity levels, such as low, medium, high and critical, and write a criterion for each. Base the criteria on factors you can observe at triage: the number and sensitivity of affected systems, data classes involved, whether the activity is ongoing or contained, potential effect on operations and customers, and any regulatory notification trigger that applies to your sector. Write down which factors move a report up or down a level and who may override the rating with a recorded reason. The output is a severity criteria document that the triage team and incident lead both use. Ask the risk owner to confirm the levels match the escalation paths in your incident response plan.
Assign triage ownership and coverage hours
Name a primary triager and a backup for each coverage window, and state the hours each window covers. Document who may close a low-severity report, who must review any closure of a high or critical report, and who is called when a report cannot be rated. Confirm the coverage model with the staff who will work it, and check whether monitoring vendors or an outsourced security operations provider share any part of the rota. The output is a responsibilities table in the runbook with names or roles, contact paths and handoff rules. The step is complete when each window has a named owner and an escalation contact who has accepted the role in writing.
Configure intake so every report gets a record
Route all intake channels, including email, phone notes, service desk tickets, SIEM and EDR alerts, and third-party notices, into one system of record. Each report should create a case record with a unique identifier, source, timestamp, reporter, initial description, triage decision and severity rating. Where a tool creates cases from alerts, configure it so duplicate alerts link to an existing case rather than opening new ones. The output is a case record template and a documented intake map showing each channel and where it lands. Check the setup by confirming that a test report from each channel produces a complete record with no manual copying.
Test the process with sample reports
Prepare a set of sample reports that cover clear incidents, false positives, reports outside scope, duplicates and borderline cases. Label these samples as illustrative and write the expected triage decision and severity for each before the test starts. Have triagers process them using only the runbook and criteria, then compare their decisions with the expected results and record every gap. Revise the checklist, criteria or ownership rules where decisions diverged, and rerun the affected samples. The output is a test record listing each sample, its expected and actual result, and the changes made. The process is ready when the team reaches consistent decisions and the test record is retained as evidence.

How an assessor tests RS.MA-02 triage records

This table sets out how an assessor samples and tests triage records for RS.MA-02, the evidence each test asks for, and the findings that appear most often. Read each row as a test step, then check the evidence column against what your own case records contain. The main takeaway is that a written severity method is only persuasive when the individual records show it was applied.

Test area	Test approach	Evidence requested	Common findings
Sample selection	Select a set of incident reports across the full review period, including reports closed as non-incidents and reports escalated later.	Complete report register or case export for the period, with the sampling basis recorded.	Sample drawn only from confirmed incidents, which hides the screening decisions that matter most.
Validation decision	Confirm each sampled report has a recorded decision that it is cybersecurity-related and needs a response, or that it does not.	Triage entry with decision, date, and a short description of what was reviewed.	Reports moved to closed without any validation decision on file.
Severity method	Compare the severity assigned to each sampled report against the written criteria, and check the criteria are the version in force on that date.	Approved severity criteria, version history, and the severity field for each sampled report.	Criteria documented in a policy but not used, with severity set by informal judgment.
Rationale	Read the justification attached to each severity and validation decision and check it cites the criteria or facts used.	Free-text rationale or structured fields linking each decision to criteria.	Closed reports with no recorded rationale or only a status change.
Reviewer and timing	Check that each decision names the reviewer and records when the report was received and when triage was completed.	Case audit trail showing user identity, timestamps and any reassignment.	Shared or generic accounts used, or timestamps missing for triage steps.
Reviewer coverage	Test whether triage was performed by someone other than a single individual and whether a named alternate covered absences.	Duty roster, on-call schedule, and records of triage performed during the sampled period.	Triage depends on one person with no documented backup and no record of cover.
Mapped control cross-check	Cross-check the triage process against the mapped controls an assessor may use: SP 800-53 Rev. 5.2.0 IR-4, IR-5 and IR-6, and ISO/IEC 27001:2022 Annex A controls 5.24, 5.26, 5.27, 5.28 and 6.8.	Incident handling procedure, incident monitoring records, incident reporting records and training records for triage staff.	Procedure written against one framework only, leaving gaps against the other control references.

Evidence that passes RS.MA-02 triage and validation review

An assessor testing RS.MA-02 looks for proof that incoming reports are checked, that the check follows written criteria, and that severity is assigned the same way each time. The six artifacts below connect the criteria, the runbook, the individual decisions and the oversight of those decisions. Each one needs an owner and a refresh routine so it still reflects practice when the assessor arrives.

Written severity criteria with version history

The severity criteria define what the organization treats as cybersecurity-related, what needs a response, and which factors (affected systems, data sensitivity, service impact, spread) move an incident up or down. Assessors check that the document has a version number, an approval date and a named approver. Keep the criteria in the same controlled repository as other incident response documents, and record every change with its reason and sign-off. Confirm that the version in force matches the one triage staff actually use.

Triage runbook with preliminary review checklist

The runbook tells the first responder how to perform the preliminary review: confirm the report is cybersecurity-related, decide whether it needs a response, record the decision, and hand off or close. The checklist should be short enough to complete during a live alert and specific enough that two analysts reach the same result from the same report. Review the runbook after each tabletop exercise or real incident, and keep dated revisions so the assessor can see it was maintained.

Triage records showing validation decisions

A sample of triage records shows the report received, the validation outcome (cybersecurity-related and needs response, or closed with rationale), the analyst, and the time of each step. Records that close a report without a response are often the ones assessors examine most closely, so the rationale must be written in enough detail to be re-read later. Case management platforms such as DFIR-IRIS keep each case as one record with an audit trail, which helps keep these entries complete. Confirm that rejected reports are retained as well as escalated ones.

Severity assignments tied to the criteria

Each triaged incident should carry a severity rating and a reference to the criteria version that produced it. An assessor will pick several records and check that the rating follows from the stated factors rather than from the analyst's judgment alone. Where the criteria require a second factor, such as data classification, the record should show it. Export these fields on a schedule so the sample reflects recent work, not only the records prepared for the audit.

Triage coverage and on-call rota records

Assessors want evidence that someone is responsible for triage at all hours the organization receives reports. Keep the duty rota, the escalation contacts and records of coverage gaps, including how gaps were covered by backup staff or a contracted service. If an outside provider performs triage, the contract and its service records belong in this set as well, with the organization still accountable for the outcome. Review rota records monthly so changes in staffing are visible.

Reviews of triage decisions

Periodic review shows that triage decisions are checked after they are made. Sampling a set of closed and escalated reports each period, comparing severity ratings with later findings, and tracking metrics such as reports closed without review or ratings changed after escalation give the organization a feedback loop. Record the sample method, the reviewer, the findings and the criteria changes that followed. Confirm the review schedule is set in advance so it is not assembled only before an assessment.

How DFIR-IRIS keeps triage decisions in one audit trail

DFIR-IRIS can hold the triage record for RS.MA-02 in one place, but it does not decide whether a report is a real incident or how severe it is. Those decisions remain with your analysts and your written criteria. The tool's role is to keep each case as a single record that holds its assets, indicators of compromise, tasks and evidence, with a full audit trail of who changed what and when. An assessor testing RS.MA-02 wants to see that a report was reviewed, that the review was recorded, and that the severity estimate traces back to defined criteria. A case record with preserved history supports all three.

Intake is where you should start. According to the DFIR-IRIS documentation, the platform can triage alerts from SIEM, EDR and REST sources into cases. Before you rely on this for evidence, confirm in your own deployment which intake sources are enabled, which alert fields are mapped into the case, and how duplicate or low-value alerts are handled, dismissed or merged. Document that mapping as part of your triage procedure. Also confirm how the severity or classification fields in the tool map to your organization's own criteria, since the tool will store whatever values your team enters. The mapping should be written down and reviewed, not left to individual analysts.

Reporting is the last piece. DFIR-IRIS can generate reports from case data, so a validation decision and its supporting notes can be exported for a control review or an external assessor. Test this before an assessment: pull a sample of closed triage cases, check that the audit trail shows the initial report, the validation step, the severity rationale and any reclassification, and confirm that the exported report carries the same information. Keep in mind that an assessor will judge the process as well as the record, so the tool should support a documented triage procedure rather than substitute for one.

What meeting RS.MA-02 triage costs in money and effort

This table lists the cost components of running RS.MA-02 triage and validation, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the questions in the last column to make a quote itemize each line.

Cost component	One-time or recurring	What drives it and how to keep it down
Triage criteria design and approval	One-time, with periodic review	Drivers: number of intake sources, severity scales already in use and how many leaders must sign off. Keep down by reusing existing incident classification. Ask the quote to itemize workshop days, drafting and approval steps.
Triage analyst time	Recurring, usually the largest line	Drivers: alert and report volume, share of false positives and on-call coverage hours. Keep down by tuning intake filters and documenting preliminary review steps. Ask the quote to state the analyst hours assumed per week and the volume basis.
Case tooling licenses	Recurring if commercial, none if open source	Drivers: user count and feature tier for commercial case management. Keep down by choosing a platform with no license fee. Ask the vendor to confirm current license terms in writing.
Self-hosting and maintenance of case tooling	Recurring, plus one-time setup	Drivers: hosting environment, backups, patching, access control and upgrade testing. DFIR-IRIS is LGPL-3.0-or-later, so license spend is removed but hosting and upkeep remain. Ask the quote to itemize infrastructure, patch cycles and who owns on-call support.
Integration with intake sources	One-time build, recurring upkeep	Drivers: number of SIEM, EDR and REST sources feeding cases and how often their formats change. Keep down by limiting first release to highest-volume sources. Ask the quote to list each source, the integration method and the test plan.
Evidence upkeep	Recurring	Drivers: volume of triage records kept, required fields and retention periods set by your own policy. Keep down by generating records from the case system rather than by hand. Ask the quote who maintains the evidence and how often it is reviewed.
Auditor sampling and walkthroughs	Recurring at each assessment cycle	Drivers: sample size the assessor selects and the number of triage decisions needing explanation. Keep down by keeping a consistent rationale field for each decision. Ask the assessor to confirm its sampling approach before fieldwork.
External review of criteria	Optional, periodic	Drivers: whether an outside party validates severity criteria and the scope of that review. Keep down by limiting review to criteria changes. Ask the quote to separate review fees from the implementation fee.

What your team, a partner and the auditor each do for RS.MA-02

Your organization owns RS.MA-02. It decides what counts as a cybersecurity-related report, what severity criteria apply and who makes each triage call. Those decisions must be made by your staff, recorded at the time they are made and reviewed when the criteria change. An assessor will look for evidence that people actually followed the criteria, so the team needs to be able to explain its own decisions, not point to a vendor document.

Criteria ownership: Approve the preliminary review questions and the severity criteria, and record who approved them and when.
Triage decisions: Staff the intake queue, decide whether each report is cybersecurity-related and needs a response, and assign an initial severity.
Records: Keep a case record for each report with the decision, the rationale and the timestamp.
Review: Periodically check a sample of closed triage decisions against the criteria and log corrections.
Ownership of changes: Track changes to criteria and tooling through your own change process.

Before relying on the process, confirm that your staff can reproduce the severity call for a sample report without consulting the partner.

How long and how much effort does RS.MA-02 triage take to set up

How much effort does it take to meet RS.MA-02 incident triage?

The effort depends mostly on alert volume, how many sources feed your intake, and how much of the triage criteria already exists on paper. RS.MA-02 asks that incident reports be triaged and validated, and NIST's two Implementation Examples describe a preliminary review to confirm a report is cybersecurity-related and needs a response, plus applying criteria to estimate severity. Effort is front-loaded: defining the intake paths, writing severity criteria, building the triage record and testing it against past reports. Then it recurs as analysts work reports and as criteria are tuned. No duration is given in the supplied facts, so ask any partner to state the effort in person-days for each component and to list the assumptions behind it.

Can a small security team set up RS.MA-02 triage without outside help?

Often yes, if the team has someone who can write severity criteria and a case system to record triage decisions. Open-source case management tools such as DFIR-IRIS can hold each report as a case with a timeline, tasks and an audit trail, and can ingest alerts from SIEM and EDR sources, but the team must still decide what counts as cybersecurity-related and what severity levels mean. Outside help is most useful for drafting criteria against your own risk register, wiring intake sources, and running a tabletop exercise on sample reports. Confirm with your own staff what they can absorb alongside daily operations before deciding.

What skills and staff time does RS.MA-02 triage require?

The work needs analysts who understand your environment, a lead who can make severity calls, and time set aside for documentation. Analysts need to read alerts and user reports, check whether they point to a security event, and record the reasons for their decision. The severity lead needs enough authority to apply criteria consistently and escalate when needed. Ask your team to estimate how many reports per week they handle and how long a preliminary review takes, since those two numbers drive staffing more than any framework requirement.

How should triage ownership work across shifts?

Assign a named owner for the intake queue at every hour the service runs, with a written handoff that carries open reports, their severity estimate and the next action. Each report should be in exactly one state at a time, so that nothing is claimed twice or dropped at shift change. Define who may re-rate severity during the night and who must be called. Test the handoff with sample reports and confirm that the case system records each change with a timestamp and the person who made it.

Can RS.MA-02 triage be certified?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. What you can have is an independent assessment that examines your triage records and reports against RS.MA-02 and related requirements, carried out by a party you engage for that purpose. That party issues its own findings. DeployOpen prepares systems, criteria and evidence for such assessments, but it does not issue audit reports, attestations or certifications. Ask any partner to confirm that distinction in writing.

What should a fixed-scope quote for RS.MA-02 triage include?

A fixed-scope quote should list the intake sources in scope, the severity criteria to be drafted or reviewed, the case system and integrations, the number of test reports used for validation, and the handover documents. It should also state what is excluded, such as 24-hour staffing, third-party monitoring or assessment fees. Ask for each deliverable, the acceptance test, the staff time you must supply, and the timeline in writing before work starts. Compare quotes on those items rather than on headline totals, and confirm whether ongoing support or testing is priced separately as a retainer.

How DeployOpen prepares RS.MA-02 triage systems and evidence

DeployOpen plans, implements and documents the self-hosted systems that receive, triage and validate incident reports for RS.MA-02, inside the client's own infrastructure. The organization keeps ownership of its triage criteria and decisions, while DeployOpen prepares the tooling, workflows and records that show how reports are validated.

How we scope

Engagements are fixed-scope, with the triage sources, criteria and deliverables agreed in writing before work starts.
The written scope names which alert sources, such as SIEM, EDR or REST feeds, feed the triage workflow.
Severity criteria and validation steps are listed as client-approved inputs, so ownership stays with the organization.

How we build

Self-hosted case management is configured so each report becomes one case with its assets, indicators and tasks.
Intake rules route alerts into cases and record the preliminary review steps used to confirm a cybersecurity-related report.
Severity fields and their criteria are set up as documented workflow steps, then tested with sample reports before go-live.

How we hand over

Handover includes configuration documentation, the triage runbook and the list of records each validation step produces.
Evidence samples show how a triage decision is logged, timestamped and linked to its case audit trail.
Operators are walked through the workflow, and the client confirms with its own assessor which evidence satisfies RS.MA-02.

How we support

Ongoing support, upgrades and continuous testing of the triage platform are available as a retainer.
Periodic review of triage criteria and workflow changes can be added to the retainer scope when the client requests it.
DeployOpen prepares evidence for assessments but does not issue audit reports; independent auditors make that determination.

RS.MA-02 Incident triage and validation