What RS.MA-03 incident categorization and prioritization requires
RS.MA-03 expects every declared incident to be categorized and prioritized so the team knows what kind of event it faces and how urgently to act. It is a Subcategory of the Incident Management (RS.MA) Category in the RESPOND Function of NIST CSF 2.0. NIST's Implementation Examples name data breach, ransomware, DDoS and account compromise as example types, and they ask the team to rank incidents by scope, likely impact and urgency. They also raise a decision that many teams make by instinct: whether to recover quickly or to keep observing the attacker and investigate further. The outcome is not a particular taxonomy. It is a consistent, documented answer to three questions: what type of incident this is, how far it reaches, and what response it deserves now.
The risk this addresses is misdirected effort. A team that treats a credential stuffing alert the same as a suspected ransomware staging event will spend its best analysts on the wrong work, and the most damaging events can wait in a queue behind noisy ones. Priority errors often surface after the fact, when a post-incident review finds that the first hours went to low-impact tasks. The practical difficulty is consistency. One shift may label an event "high" because it touches a production database, while another shift labels the same pattern "medium" because the SIEM rule fired at a lower score. Ticketing, EDR and SIEM tools each carry their own severity fields, and those fields rarely map to one another.
Confirm three things before relying on the section's logic. First, whether your incident taxonomy names categories that match the examples NIST gives, and whether each category has a documented default response strategy. Second, which severity criteria apply to scope and impact, and who can override them during an incident. Third, how the category and priority fields are stored in your case management platform, so that a DFIR-IRIS case or equivalent record can show the decision and its rationale. For background on the change, NIST's transition spreadsheet shows that RS.MA-03 took over CSF 1.1 RS.AN-4 under a new identifier and absorbed part or all of RS.AN-2, so existing 1.1 mappings should be re-keyed rather than assumed to carry over. The full framework text is in NIST CSWP 29.
Which systems, teams and third parties fall under incident categorization
Categorization and prioritization only work when the right alerts reach the right people with the right context. The decisions below set which sources feed incidents, who may assign or change a category, which data raises impact, and which third parties act on the organization's behalf.
Monitoring sources that feed incidents
Decide which signals become incident candidates: SIEM correlation alerts, EDR detections, cloud control plane and identity logs, email security events and reports from users. Each source brings its own noise level and timestamp format, so categories applied to one feed may not hold for another. Adding a source usually means new category rules, new test cases for triage and a check that events carry enough asset and account detail to assign a type such as account compromise or ransomware. Confirm which sources are ingested today and which are only viewed in consoles.
Owners of triage and category changes
Name the team that assigns the initial category and the role allowed to change it later. If a SOC analyst can downgrade a suspected ransomware case without review, priority decisions depend on one person's judgment. Write down who may override a category, what evidence they must record and who is told when a category rises. Effort grows with the number of teams involved, because each handoff needs a shared definition of the categories and a log of changes.
Data classes that raise impact
Impact estimates change when an incident touches regulated personal data, payment card data or operational technology that controls physical processes. An account compromise on a system holding health records or cardholder data may need a higher priority than the same event elsewhere, and the notification duties that follow may differ. Map where these data classes live, including backups and third-party platforms, so analysts can see the affected classes when they score an incident. Ask which data owners must be contacted for each class.
Managed providers that categorize incidents
When a managed security service provider monitors alerts or runs the first triage, the provider's categories and severity scales become part of the organization's record. Agree in writing which categories the provider uses, which of them trigger a call to the organization, how priority is set outside working hours and who signs off a downgrade. Confirm that the provider's case records can be exported to the organization's own system, since a category assigned only in the provider's portal weakens later reviews and reporting.
Business owners and their dependencies
Priority depends on what an affected system does for the business, so the owners of critical services should be part of the scoping. A compromised build server, a payments gateway and a internal wiki differ in scope and impact even when the technique is the same. Record which business services depend on each asset and who can confirm downtime tolerance. Expect the work to start with an asset inventory and dependency map, because categorization without them rests on guesses.
Third-party platforms and cloud providers
Incidents often start in a service the organization does not run, such as a SaaS identity provider or a hosting platform. Decide which provider notifications count as incident inputs, how their severity language maps to the organization's categories and who receives them when the provider's status page and direct notices disagree. Check the contract for notification timing and the points of contact, and confirm which evidence the provider will supply to support the category chosen.
How an assessor tests incident categorization and prioritization
This table compares what an assessor does, the evidence they ask for and the findings they commonly raise for RS.MA-03. Read each row as a question the assessor will put to your incident lead and your case records, and prepare the evidence before the fieldwork starts.
| Test area | What the assessor does | Evidence requested | Common findings |
|---|---|---|---|
| Interview with the incident lead | Asks how incidents are assigned a type and a priority, who makes the call and what happens when the first call turns out wrong. | Named incident lead, a short walkthrough of a recent case, and any role descriptions covering categorization decisions. | Lead describes a process that differs from the written procedure, or nobody can name who owns the priority decision. |
| Review of the categorization taxonomy | Checks that incident types are defined in writing, with examples such as data breach, ransomware, DDoS or account compromise, and that the categories are mutually clear. | Approved taxonomy document, version history, and the list of categories configured in the case management tool. | Categories exist only in tool drop-downs, lack definitions, or overlap so that the same incident could fit two types. |
| Review of prioritization criteria | Looks for written criteria that rank incidents by scope, likely impact and urgency, and checks that the criteria are applied consistently. | Written priority matrix or scoring rules, with the owner and approval date. | Priorities are set by judgment alone, or the matrix does not cover impact on regulated data or critical services. |
| Sampling of closed incidents | Selects a sample of closed incidents across the period and checks that each record shows a category and a priority. | Case export with category, priority, timestamps and closure notes for each sampled incident. | Some closed incidents have no category or priority, or the category was changed after closure with no reason recorded. |
| Check of category against taxonomy | Compares the category on each sampled record with the taxonomy definitions and with the facts in the case notes. | Sampled records alongside the taxonomy and the investigation timeline. | Categories that do not match the taxonomy, or free-text labels such as misc or other used in place of defined types. |
| Check of response strategy records | Looks for a recorded decision on whether to prioritize fast recovery or continue observing the attacker or investigating further. | Decision entries in the case record, with the reasoning, approver and time of decision. | No record of why a fast-recovery or investigate-further choice was made, or the decision appears only in chat messages. |
| Review of change control on priority | Checks whether priority changes during an incident are logged with who changed them and why. | Audit trail or activity log for priority and category fields. | Priority is overwritten without an audit trail, so the assessor cannot tell what was known at each stage. |
| Review of training and calibration | Asks whether responders are trained on the taxonomy and whether reviewers compare decisions to check consistency. | Training records, calibration notes or peer review samples. | Staff learned the taxonomy informally, and different shifts classify the same type of incident differently. |
How to implement incident categorization step by step
This sequence turns RS.MA-03 into working rules: a category list drawn from your real incident types, priority criteria, named decision owners, a recovery-versus-investigation rule, configured tooling and tested workflows. Each step ends with an artifact you can show an assessor.
Build the incident category taxonomy
Start by reviewing the incidents your organization has actually handled, near misses from your monitoring, and the threat types your sector sees most. Draft a short category list that covers types such as data breach, ransomware, DDoS and account compromise, and add any types specific to your environment. Keep each category defined by what it looks like in practice so analysts can pick one without debate. The output is a written category taxonomy with a one-line definition and example indicators for each category, approved by the incident response lead.
Write prioritization criteria for scope, impact and urgency
Define the factors that set priority: how much of the environment or how many users, data or systems are affected (scope), the likely effect on operations, customers, legal obligations and safety (likely impact), and how quickly damage grows if nothing is done (urgency). Convert these into levels with observable thresholds, such as which systems count as critical. NIST's Implementation Examples for RS.MA-03 frame priority around these three factors. The output is a priority matrix that maps category, scope, impact and urgency to a priority level, reviewed by business owners of the critical services.
Assign decision rights for categories and priority
Name who assigns the initial category and priority, usually the first responder or triage analyst, and who may change them later, such as the incident lead or a senior responder. Record who must be notified when priority rises to the highest level. Separate the right to change a category from the right to change a priority if your team needs that control, and require a written reason for every change. The output is a responsibility table or RACI entry for categorization that the incident response plan references, so an assessor can trace who acted on each incident.
Set the recovery versus investigation decision rule
Document how the team decides between restoring service quickly and observing the attacker or investigating further. The rule should name the conditions that favor each path, such as active data exfiltration, evidence that would be lost on restore, regulatory reporting needs or the business impact of continued downtime. Name the approver for each decision and state that the choice is recorded with its rationale. Confirm the rule with legal, the business owner and the forensic provider if you use one. The output is a one-page decision rule attached to the response procedure.
Load categories and priority fields into the case tool
Configure the ticketing, case or SIEM tool so every incident requires a category and a priority before it can move forward. Restrict edit rights to the roles named in the decision rights table and make every change to these fields write to the audit trail. Connect alert sources so that the category and priority fields are populated from the taxonomy rather than free text. Open-source case tools such as DFIR-IRIS keep each case as one record with an audit trail, which can support this evidence, but confirm the exact field and permission model in your version. The output is a configured case template with a test record showing the required fields and logged changes.
Test categorization with tabletop scenarios
Run tabletop exercises using written scenarios that cover several categories, including one that forces a trade-off between fast recovery and further investigation. Ask participants to categorize, prioritize and record the decision rule in the tool while a facilitator observes. Compare each result with the matrix and note where people disagreed or the criteria were unclear. Update the taxonomy, thresholds or decision rule to close the gaps, and schedule a re-run after changes. The output is a tabletop record with scenarios, outcomes, identified gaps and the corrective changes made, which serves as evidence that the process works in practice.
Evidence that satisfies RS.MA-03 and how to keep it current
An assessor testing RS.MA-03 looks for written rules, applied consistently to real incidents, and proof that those rules were revisited when experience showed they needed to change. The cards below name the artifacts that carry that proof and the routine that keeps them accurate between formal reviews.
Written categorization taxonomy with version history
This is the document that defines each incident type your organization recognizes, such as data breach, ransomware, DDoS or account compromise, and the criteria that place an event in one type. Keep a version history with the date, author and reason for each change so an assessor can see how the taxonomy evolved. Check that every type has a named owner and that the categories are mutually clear enough that two responders would file the same event under the same type.
Prioritization criteria by scope and impact
This artifact states how responders rank incidents using scope, likely impact and urgency, as the RS.MA-03 Implementation Examples describe. Write the criteria as observable conditions, such as number of affected systems, presence of regulated personal data or service disruption to a critical process, so two analysts reach the same priority. Confirm that the scale ties to the response timelines your incident response plan sets, because a priority label that triggers no action is hard to defend.
Case records with category, priority and rationale
Each incident case should record the assigned category, the priority, and a short written rationale explaining why those values were chosen. This is the artifact that proves the taxonomy and criteria were applied in practice, not only written down. Sample closed cases during audit preparation and confirm that the rationale references the criteria, that the category changed when new facts emerged, and that reclassifications are logged rather than overwritten. A case management tool with an audit trail, such as DFIR-IRIS documentation, can keep these fields and their history together.
Recorded response strategy decision
RS.MA-03 also covers choosing a response strategy, including balancing fast recovery against observing the attacker or investigating further. Record which path was chosen for each significant incident, who approved it, and what was weighed, such as keeping a compromised account live to gather evidence versus cutting access immediately. Without this record, an assessor cannot tell whether the decision was deliberate or accidental. Keep the decision entries in the same case record as the categorization so they are retrievable together.
Taxonomy review after exercises and real incidents
A taxonomy that never changes after an incident suggests it was never tested. Keep minutes or a change log showing that the category list and priority criteria were reviewed after each tabletop exercise and after any significant real incident, with the specific changes made or the reason none were needed. Tie each review to the version history of the taxonomy so the two artifacts corroborate each other. Confirm with your exercise lead that lessons from exercises are routed into this review rather than left in a separate report.
Quarterly sample of recent cases
Between audits, a recurring sample keeps the evidence honest. Each quarter, a reviewer who did not handle the cases should pull a set of recent incidents and check that each carries a category, a priority, a rationale and a recorded strategy decision where one applies, and that the labels match the written criteria. Record the sample, the exceptions and the corrective action. Ask your assessor early whether they expect a specific sample size, because the expectation is set by the assessor and your own policy, not by NIST.
How DFIR-IRIS can hold categorization records and audit trails
DFIR-IRIS can give an assessor one place to see how an incident was categorized and prioritized, and how those decisions changed over time. It is an open-source case management platform licensed under LGPL-3.0-or-later. Each case is kept as a single record that holds the affected assets, indicators of compromise, tasks and evidence, with a full audit trail. When the category or priority of a case is changed, the record of that change sits alongside the case itself, so the question of who categorized the incident as account compromise, when it was re-rated as ransomware, and what drove the change can be answered from the case rather than reconstructed from chat logs or email. The platform's documentation at DFIR-IRIS documentation is the starting point for confirming how this history is exposed in your version.
Intake is where categorization consistency usually breaks down, and DFIR-IRIS can help here by triaging alerts from SIEM, EDR and REST sources into cases. Alerts that arrive from different tools are turned into cases through one path, which means the same type of event is more likely to be handled the same way regardless of which analyst picks it up. Before you rely on this, confirm which alert sources your deployment connects, how alerts are mapped to case fields and whether your version exposes category and priority fields that you can set and report on. Test these with a few illustrative alerts in a non-production instance before they are used to support a real response.
The organization still owns the taxonomy and the criteria. DFIR-IRIS records the categories and priorities you define, but it does not decide what counts as a ransomware incident or how scope and likely impact translate into a priority. Write those definitions first, then configure the platform to match them. Confirm the license terms with your legal or procurement team, since LGPL-3.0-or-later carries obligations that depend on how the software is modified and distributed. A deployment that is customized or embedded in other products may need a separate review before it is put into production.
What meeting RS.MA-03 costs in money and effort
This table lists the cost components of categorizing and prioritizing incidents under RS.MA-03, marks each as one-time or recurring, and names what pushes it up or down. Use it to structure a quote request, since no supplied figures give prices or durations for these items.
| Cost component | One-time or recurring | Who is paid or who spends effort | What drives it up or down |
|---|---|---|---|
| Case management or ticketing licenses | Recurring | Software vendor, or no license fee for self-hosted open source | Number of users, teams and cases; ask whether the quote covers hosting, support tiers and seat growth |
| SIEM, EDR and ticketing integration | One-time build, recurring upkeep | Implementation partner or internal platform engineers | Number of incident sources and their API stability; each new source adds mapping and testing work |
| Writing the incident taxonomy and criteria | One-time | Internal incident response lead, with legal and compliance input | Number of incident types (data breach, ransomware, DDoS, account compromise) and regulatory overlap that adds reporting categories |
| Configuring case fields, severity and priority logic | One-time, then recurring when changed | Platform engineers or implementation partner | Number of fields, automation rules and business units with separate impact scales |
| Recurring case review and taxonomy updates | Recurring | Incident response staff and service owners | Incident volume, number of teams and how often new threat types emerge; review cadence is set by the organization |
| Tabletop and exercise time for triage decisions | Recurring | Incident response, IT operations and business stakeholders | Number of scenarios exercised per year and the number of decision makers who must attend |
| Auditor sampling and evidence preparation | Recurring per assessment cycle | Internal compliance staff, with the independent auditor testing samples | Size of the incident population, retention of case records and whether the audit trail is complete and exportable |
| Maintenance of self-hosted open-source tooling | Recurring | Internal platform team or a retained implementation partner | Upgrade frequency, hosting model, backup routines and security patching; no license spend, but effort continues |
Who owns incident categorization, who can help, and where the auditor stops
Your organization owns the control. RS.MA-03 asks that incidents be categorized and prioritized, and the decisions behind that outcome belong to your incident response function: which incident types exist, how scope and impact are weighed, what urgency means for each type, and which response strategy applies when fast recovery conflicts with investigating the attacker further. These choices reflect your risk appetite, legal duties and business priorities, so they cannot be delegated to a vendor.
- Taxonomy ownership: Maintain the list of incident categories, such as data breach, ransomware, DDoS or account compromise, with written definitions and examples that analysts apply the same way.
- Prioritization criteria: Set the rules for scope, likely impact and urgency, and document who approves changes to them.
- Assignment decisions: Decide who may assign an incident to a category and priority, and what evidence must be recorded with that decision.
- Response strategy choices: Decide when containment takes precedence over observation of the attacker, and who authorizes that trade-off.
- Downgrade authority: Name the roles allowed to lower a priority, and require a recorded reason and a second approval for high-impact incidents.
Check that each decision has a named owner, a review date and a written record that an assessor can sample.
An implementation partner such as DeployOpen can prepare the systems and evidence that support RS.MA-03 inside your own infrastructure. The partner works on the tooling, documentation and exercises that let your team apply its decisions consistently. It does not set your taxonomy, approve priorities or decide response strategy, and it does not issue any assurance statement about the outcome.
- Case tool configuration: Deploy and configure a self-hosted case management platform, for example DFIR-IRIS, so that categories, priority fields and status values match your approved taxonomy.
- Integrations: Connect alert sources such as SIEM, EDR and REST feeds so that incidents enter the case queue with the fields needed for categorization.
- Criteria documents: Draft categorization and prioritization procedures from your approved decisions, for your review and sign-off.
- Tabletop and simulation tests: Plan exercises that run mixed scenarios, such as ransomware alongside a suspected data breach, and record how analysts categorized and prioritized them.
- Evidence preparation: Organize case records, audit trails and exercise reports so your team can present them to an assessor.
When scoping a partner, ask which of these items are in the fixed-scope deliverables and who retains ownership of the criteria documents after handover.
An independent auditor, assessor or certification body tests whether RS.MA-03 is operating as your organization describes it. The auditor samples incidents, reads the categorization and priority decisions, checks that the criteria were followed, and asks for evidence of review. Only an independent party can issue a report or certificate, and NIST does not offer certification or endorsement of CSF implementations.
- Independence limits: An auditor who wrote your taxonomy or set your priority criteria cannot then test them without a conflict, so keep design and testing with separate people.
- Sampling: Expect the auditor to select closed incidents across categories and check whether the recorded priority matches the documented criteria.
- Override review: Expect questions about each downgrade, who approved it and whether the reason was recorded at the time.
- Exercise records: Expect review of tabletop results and whether gaps led to changes in the criteria.
- Scope of report: Confirm with the auditor which framework, which version and which Subcategories the engagement covers, since the RS.MA-03 outcome is only one part of the CSF Core.
Before engaging any assessor, ask how it handles independence, what evidence it will sample and whether it will issue a report or a gap analysis only.
Where organizations fall short on incident categorization
Why do SOC and incident response teams end up using different incident categories?
Usually because each team built its own taxonomy for its own tools, so the same event carries two labels. The SOC tags alerts by detection source, while the incident response team tags cases by attack type such as ransomware, data breach or account compromise. Handoffs then lose meaning, and reports cannot be compared across months. The fix is one shared category list, owned by a single role, that both teams must use in the ticketing or case system. Each category should have a written definition, examples and a mapping from any legacy SOC alert names. Review the list whenever a tool or team changes, and record the version in use so that old incidents can still be read against the list that applied at the time.
What goes wrong when incident priorities have no written impact criteria?
Priority becomes a judgment call made under pressure, so two analysts can rank the same incident differently and senior staff override them without a record. NIST's implementation examples for RS.MA-03 describe prioritizing by scope, likely impact and urgency, so those three factors need written definitions. Specify what counts as broad scope, which systems or data classes raise impact, and what makes an incident urgent, such as active spread or an upcoming regulatory deadline. Put the criteria into a priority matrix that the case system calculates or prompts for. Ask the business owners of critical services to approve the matrix before an incident occurs, because impact is hard to define during one.
Why should the response strategy choice be recorded in the incident file?
A response strategy decides whether the team restores service quickly or keeps the attacker under observation for further investigation, and those two goals often conflict. When the decision is not written down, auditors and post-incident reviewers cannot tell whether it was deliberate, and the people who made it cannot explain it later. Record the options considered, the choice, the approver and the reason, with a timestamp, in the same case record as the category and priority. Revisit the decision if new facts change the scope. A short template with fields for these items is usually enough, and the case tool should keep the entries in its audit trail.
Why do incident categories need revisiting after tabletop exercises?
Exercises expose categories that are too broad, overlapping or missing an attack type the organization actually faces. If the category list is never updated after a tabletop or a technical exercise, the same confusion repeats in the next real incident. After each exercise, collect the categorization decisions that took longer than expected, note where two categories applied, and decide whether to split, merge or define a category more precisely. Record each change with a date and the exercise that prompted it. NIST's improvement guidance under ID.IM supports feeding exercise results into operational plans, so treat the category list as one of those plans.
What happens to reporting when cases are closed without a category?
Uncategorized cases cannot be counted, trended or assigned to a playbook, so the organization loses the ability to see which threats are growing. Closed cases without a category also weaken evidence for regulators and customers who ask how incidents are handled. Make the category a required field before a case can move to closed, and require a reason code if the team chooses an 'other' or 'undetermined' value. Review closed cases with no category each month and assign an owner to fix the records. The case management tool should enforce these rules rather than relying on memory, and the closure report should show the number of uncategorized cases so that leaders can see the gap.
Can an organization set up incident categorization without an outside partner?
Yes, an internal team can write the category list, priority matrix and strategy template, provided the owners have the authority to approve them and the time to maintain them. The work is mostly governance and documentation, so the main cost is staff time from security operations, incident response, and the business owners of critical services. An implementation partner can help configure the case system to enforce the fields, connect alert sources, and prepare evidence for an assessment, but the organization still owns the decisions. Ask any partner to state the scope in writing, including which categories, workflows and records it will deliver, and who will maintain them afterward. DeployOpen plans and implements self-hosted open-source platforms, such as DFIR-IRIS, inside the client's own environment, and prepares the configuration and evidence. Independent assessors, not implementers, judge whether the controls meet a framework.
Questions buyers ask about RS.MA-03 effort, cost and outside help
How much effort does RS.MA-03 take for a small team?
For a small team, the effort is mostly in writing down decisions rather than in tooling. RS.MA-03 asks that incidents be sorted by type, such as data breach, ransomware, DDoS or account compromise, and ranked by scope, likely impact and urgency. The work starts with a short, agreed list of incident categories, a severity scale tied to business impact, and a simple rule for which response strategy applies to each category. Once those exist, most of the recurring effort is applying them to each incident and reviewing how they were used after each event. The total effort depends on how many incident types you handle and how often your triage decisions change. Ask any provider to estimate effort in person-days for your environment and list which decisions your own staff must make.
Can an organization implement RS.MA-03 without an outside partner?
Yes, an organization can implement RS.MA-03 with its own staff, because the outcome is an internal decision process rather than a product purchase. Internal teams usually need to agree on categories, define severity and impact criteria, name who can change a priority, and document the response strategy options, including the trade-off between fast recovery and investigating further. A partner can help where internal staff lack time or experience, for example by preparing a case management system, testing the categories against past incidents, or writing runbooks. Whatever you choose, the organization owns the decisions. Confirm with any provider exactly which parts of the work they will perform and which remain yours.
What does RS.MA-03 require from security and operations staff?
RS.MA-03 needs input from both security and operations staff because prioritization depends on business impact as much as technical severity. Security staff typically define incident types, indicators and the technical scope of an event. Operations and business owners supply the information on which systems are critical, what downtime costs and how urgent a fix must be. Someone must hold the authority to set or override priority during an incident, and that role needs a backup. Staff also need practice with the categories, which is usually done through tabletop exercises. Ask whether your team has named owners for each decision point before any engagement begins.
How long does it take to implement RS.MA-03?
No implementation duration has been supplied for this topic, so treat any timeline as unconfirmed until it is written into a scope. The main drivers are the number of incident types you define, how much of your current process is undocumented, how many business units must agree on impact criteria, and whether you need a case management tool configured. Organizations with an existing incident response plan and a tested triage process usually move faster than those starting from scratch. Ask for a timeline broken into phases, with each dependency on your staff or systems stated explicitly.
Does NIST certify compliance with RS.MA-03 or the CSF?
No, NIST does not certify compliance with RS.MA-03 or any other part of the CSF. 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. Only an independent assessor or auditor can give an opinion on how well your implementation matches the framework, and that opinion is their report, not a NIST certificate. An implementation partner, including DeployOpen, can prepare systems, procedures and evidence, but it does not issue reports or certificates. Be cautious of any vendor who claims to certify CSF compliance.
What should a written quote for RS.MA-03 work include?
A written quote should describe the work in terms of deliverables, not hours alone. Ask for the following items to be stated:
- The incident categories and severity criteria to be defined, and how many rounds of review are included
- Which systems, case records or tools will be configured, and who owns them afterwards
- Which tests or tabletop exercises will check the categories against realistic scenarios
- What evidence will be handed over, such as procedures, decision logs and training records
- Which responsibilities stay with your staff, and what happens if scope changes
- What is one-time work and what recurs, such as review cycles or retainer support
DeployOpen agreements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to confirm these points in the same form.
Which parts of RS.MA-03 are usually outsourced?
Organizations most often outsource the preparation work that needs specialist time, such as drafting the categorization scheme, configuring a case management platform, and running a tabletop exercise against past incidents. The decision on priority during a live event, and the accountability for it, usually stays inside the organization. Ongoing review of how categories perform, and support for changes to the scheme, can be arranged as a retainer if your team wants continued help. DeployOpen works on self-hosted platforms inside your own infrastructure, so your incident data stays under your control. Confirm where any provider will store case data and who can access it.
How DeployOpen works on this
DeployOpen works on RS.MA-03 by preparing the systems, categorization criteria and evidence trail that your incident responders use inside your own infrastructure. We do not decide your severity model or issue any assessment result; your organization owns those decisions, and an independent assessor reviews the outcome.
How we scope
- The written scope lists which incident types your categories must cover, such as data breach, ransomware, DDoS and account compromise.
- Scope names the systems, queues and alert sources (SIEM, EDR, REST feeds) that feed categorization and prioritization.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- We configure the case management platform so each incident carries a category, scope, impact and urgency field from intake onward.
- We integrate alert sources so triage data arrives in one record with assets, indicators, tasks and evidence attached.
- We test categorization and priority logic against tabletop scenarios and document where analysts must make judgment calls.
How we hand over
- You receive a written categorization taxonomy, priority matrix and response strategy guide mapped to RS.MA-03 for your review.
- Runbooks explain how the platform records the category, the decision to contain or keep observing, and who approved each change.
- Evidence exports show case history and audit trail entries so your assessor can trace how each incident was prioritized.
How we support
- Support covers upgrades, backups and configuration changes to the case platform after handover, scoped in a separate agreement.
- Continuous security testing can check whether categorization rules still hold as new attack types and alert sources appear.
- Ask any provider to confirm in writing which evidence your organization must retain and which parts the independent assessor will review.
