Set up a PSIRT: services, intake, triage, SLAs and the CNA role

A product security incident response team handles vulnerabilities in the products and services a company ships: it receives reports, gets them triaged and fixed, and tells customers what to do. The FIRST PSIRT Services Framework puts the difference simply: an enterprise CSIRT focuses on the security of the organization's own systems and networks, while the PSIRT focuses on products. The two must work together, because an exploited product vulnerability is both a PSIRT case and, for a SaaS provider or its customers, an incident.

NIST SSDF task RV.1.3 asks for a policy on vulnerability disclosure and remediation and gives "have a PSIRT and processes in place" as an example. Small companies can run the PSIRT function with a part-time lead and an on-call rotation; what matters is that every report has an owner and a clock from the moment it arrives.

The framework groups PSIRT work into six service areas, each with numbered services. Nobody provides all of them on day one. Use the list to decide what you provide now, what later, and what you leave to others, and write that down in the PSIRT charter.

The framework describes three models. Pick by portfolio and size, then document reporting lines and authority in the charter, because a PSIRT that cannot make product teams act will miss its targets.

Write the roles down before the first case. The RACI below is a starting point; R does the work, A is accountable, C is consulted, I is informed. Security champions, described in /frameworks/security-champions-program/, are natural product-team contacts.

Publish one documented route and accept reports wherever they land. The VDP and security.txt are the front door; see /domains/appsec/vulnerability-response/vdp-bug-bounty-pentest/ for both. Support staff need a rule to forward anything that looks like a vulnerability report to the PSIRT queue the same day, and the PSIRT needs to watch upstream advisories for the components in its SBOMs, which the framework calls monitoring product component vulnerabilities.

Acknowledge every report with a case ID and the next update date, even before triage. The ticket should record the source, because the framework treats finders who report often (established finders) differently in qualification: their reports usually need less proof before reproduction starts.

• External finders: VDP form or the security.txt contact; bug bounty platform if you run one.
• Customers: through support, with a forwarding rule and a template that asks for version and impact.
• Upstream suppliers and open-source projects: advisories for components in your SBOMs; see /domains/appsec/vulnerability-response/dependency-vulnerability-response/.
• Coordinators such as CERT/CC, which runs the VINCE platform for multi-party cases, and national CSIRTs.
• Internal sources: penetration tests, code review, scanners and incident investigations.

Qualification decides whether the report is in scope, whether it describes a vulnerability in a supported product version, and whether it duplicates a known case. Reproduction confirms the behavior on a supported version with synthetic data, without widening exposure. Score a CVSS 4.0 vector for the advisory and the CVE record, and decide priority with exploitation, exposure and reachability as in /frameworks/vulnerability-prioritization/; a KEV listing or a report of exploitation in the wild moves the case to the exploited track at once.

Record a decision for every report, including "not a vulnerability" with the reason and "not affected" with evidence, which may become a VEX statement for customers. If the finder disagrees, follow the evidence-boundary approach in /domains/appsec/vulnerability-response/coordinated-disclosure/.

ISO/IEC 29147:2018 and 30111:2019 describe the disclosure and handling processes but leave the timings to you, so set targets, publish the ones that finders care about and measure every case. Outside expectations shape them: Google Project Zero gives vendors 90 days to make a fix available and 7 days for bugs exploited in the wild, and many researchers follow similar deadlines. The EU Cyber Resilience Act adds a 24-hour early warning for actively exploited vulnerabilities in products in scope, from 11 September 2026.

Keep each case as structured data, whatever tracker you use, so you can report on it and so the same fields feed the advisory, the CVE record and the CSAF document. The schema below names the source, products with VEX-style statuses, the state, severity and vector, CWE, exploitation, the CVE, any embargo date and timestamps for each stage. It validates with Ajv 8 against JSON Schema draft 2020-12.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://psirt.example/schemas/psirt-case.json",
  "title": "PSIRT case",
  "type": "object",
  "required": ["id", "source", "products", "state", "severity", "received", "owner"],
  "properties": {
    "id": {"type": "string", "pattern": "^PSIRT-[0-9]{4}-[0-9]{4}$"},
    "source": {"enum": ["vdp", "bug-bounty", "customer", "internal", "upstream", "coordinator", "researcher-public"]},
    "products": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["name", "versions", "status"],
        "properties": {
          "name": {"type": "string"},
          "versions": {"type": "string"},
          "status": {"enum": ["under_investigation", "known_affected", "known_not_affected", "fixed"]}
        }
      }
    },
    "state": {"enum": ["received", "acknowledged", "triaged", "fixing", "fix-released", "disclosed", "closed", "rejected"]},
    "severity": {"enum": ["critical", "high", "medium", "low", "none", "unknown"]},
    "cvss_vector": {"type": "string", "pattern": "^CVSS:(3\\.1|4\\.0)/"},
    "cwe": {"type": "array", "items": {"type": "string", "pattern": "^CWE-[0-9]+$"}},
    "exploited": {"type": "boolean", "description": "Reliable evidence of exploitation; starts CRA Article 14 clocks for in-scope products"},
    "cve": {"type": "string", "pattern": "^CVE-[0-9]{4}-[0-9]{4,}$"},
    "embargo_until": {"type": "string", "format": "date"},
    "owner": {"type": "string"},
    "received": {"type": "string", "format": "date-time"},
    "acknowledged": {"type": "string", "format": "date-time"},
    "triaged": {"type": "string", "format": "date-time"},
    "fix_released": {"type": "string", "format": "date-time"},
    "disclosed": {"type": "string", "format": "date-time"},
    "advisory": {"type": "string", "format": "uri"}
  },
  "additionalProperties": false
}

Run a small report every day or week over the case records. The script applies the example targets and marks each stage as met, missed, open with its due date, or overdue. On 10 October 2026, with three sample cases, it reported a critical case received on 1 September whose fix was overdue, a customer report received on 6 October whose acknowledgement was overdue, and an exploited high-severity case whose 7-day fix target had passed, with a reminder to check CRA reporting.

"""Report each PSIRT case against an example SLA policy (calendar days, local choices).

Usage: python sla_status.py cases.json 2026-10-10T12:00:00Z
"""
import json
import sys
from datetime import datetime, timedelta

POLICY = {  # target days from "received"; exploited cases use the "exploited" fix target
    "acknowledge": 2,
    "triage": 7,
    "fix": {"critical": 30, "high": 60, "medium": 90, "low": 180, "exploited": 7},
}


def ts(value):
    return datetime.fromisoformat(value.replace("Z", "+00:00"))


def status(case, now):
    received = ts(case["received"])
    checks = [("acknowledge", "acknowledged", POLICY["acknowledge"]), ("triage", "triaged", POLICY["triage"])]
    if case["severity"] in POLICY["fix"]:
        days = POLICY["fix"]["exploited"] if case.get("exploited") else POLICY["fix"][case["severity"]]
        checks.append(("fix", "fix_released", days))
    for stage, field, days in checks:
        due = received + timedelta(days=days)
        done = case.get(field)
        if done:
            state = "met" if ts(done) <= due else "missed"
        else:
            state = "OVERDUE" if now > due else f"open, due {due:%Y-%m-%d}"
        yield stage, state


if __name__ == "__main__":
    cases = json.load(open(sys.argv[1], encoding="utf-8"))
    now = ts(sys.argv[2])
    for case in cases:
        line = "; ".join(f"{stage} {state}" for stage, state in status(case, now))
        flag = " [exploited: check CRA Article 14 reporting]" if case.get("exploited") else ""
        print(f"{case['id']} {case['severity']:8} {line}{flag}")

A CNA assigns CVE IDs and publishes CVE records for vulnerabilities within an agreed scope, usually its own products. Becoming one lets you publish authoritative records on your own schedule, with your own CWE, CVSS and version data, instead of waiting for another CNA. Under the CNA Operational Rules 4.2.0, effective 25 August 2026, a CNA should assign an ID when it has reasonable evidence of a vulnerability that is or will be publicly disclosed and is in its scope; must publish the record within 72 hours of disclosing the ID; and every record must name at least one affected product, a problem type (preferably a CWE), a description and a public reference. The rules also say a CNA must not use the type of technology, such as cloud or AI, as the only reason to decide whether to assign, and provide an exclusively-hosted-service tag for vulnerabilities that exist only in a hosted service.

To join, a CNA needs a scope definition, a public vulnerability disclosure policy and a public place where it publishes advisories, and it onboards through a Root. Organizations in Europe can now join under the ENISA Root. If you are not a CNA, ask the CNA whose scope covers your product: a vendor CNA, GitHub for open-source projects hosted there (GitHub is a CNA and assigns IDs for repository security advisories), or a CNA of last resort. See /domains/appsec/vulnerability-response/security-advisories-csaf-vex/ for publishing the record and the advisory.

Many vulnerabilities affect more than one vendor: a shared library, a protocol, or your component inside someone else's product. FIRST's "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure" (version 1.1, 2020) covers the common cases, from a vulnerability with no affected users to public disclosure or exploitation before the vendor knew. Its practical advice: give vendors a reasonable embargo to investigate and fix, agree timelines before disclosure and tell downstream vendors clearly, pick a single lead coordinator when several are involved, and set up upstream and downstream channels before you need them.

The PSIRT framework adds the intermediate-vendor case: if you supply components to other vendors, notify their PSIRTs of vulnerabilities in what you supply, and put timely notification into your contracts. For your own suppliers, ask for the same.

• Time to acknowledge, triage and fix by severity, as medians and as the share of cases within target.
• Cases overdue at each stage today, with owners.
• Share of vulnerabilities fixed before public disclosure, and cases disclosed by others first.
• Advisory quality: revisions caused by wrong version ranges or missing products.
• Root causes by CWE, fed to developer training and to the vulnerability classes the company wants to eliminate.
• Finder experience: repeat reporters and complaints about silence, from the case history.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. FIRST: PSIRT Services Framework 1.1
2. FIRST: Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure. Version 1.1 (Spring 2020).
3. CVE Program: CNA Operational Rules 4.2.0. Effective 25 August 2026.
4. CVE Program: CVE Numbering Authorities
5. ENISA: Join the global CVE Program under the ENISA Root
6. GitHub Docs: repository security advisories (GitHub as a CNA)
7. CERT/CC: VINCE coordination platform
8. CERT/CC Guide to Coordinated Vulnerability Disclosure
9. Google Project Zero: vulnerability disclosure policy
10. NIST SP 800-218: SSDF 1.1 (RV.1.3). Version 1.1 (February 2022).

Reference information

Tags

Incident responseVulnerability managementVulnerability disclosure

SDLC phase

Maintenance

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring