Intake and Triage Procedure

1. Intake Objectives

The intake process has four objectives:

1. acknowledge and preserve useful reports;
2. identify unsafe material early;
3. determine whether PCL can responsibly handle the case;
4. route the case to review, coordination, rejection, or referral.

Intake is not exploitation, confirmation testing, or public validation.

2. Intake States

State	Meaning	Next action
New	Report received but not screened	perform safety and authorization screen
Restricted	Contains sensitive material	limit access and review handling
Needs clarification	Missing key facts	ask minimal clarifying questions
Accepted for review	Suitable for technical triage	assign reviewer
Referred	Better handled by another coordinator	document referral path
Rejected	Unsafe, unsupported, or out of scope	close with minimal record
Coordinating	Vendor or maintainer contact active	maintain timeline
Ready for publication review	Public artifact drafted	run release checklist
Closed	No further action planned	retention decision

3. Initial Screen

Within intake, check:

• whether the report is readable;
• whether attachments are expected;
• whether sensitive data appears;
• whether exploit material is included;
• whether the reporter claims authorization;
• whether the target is identifiable;
• whether the report creates immediate safety concern;
• whether a legal or coordination hold may be needed.

Do not run untrusted attachments on a production workstation. Do not execute submitted code.

4. Minimum Viable Report

A report is generally triageable when it contains:

• affected vendor or product;
• affected version, endpoint, component, or condition;
• short vulnerability description;
• security impact;
• authorization basis;
• minimized evidence;
• reporter contact or statement that contact is unavailable;
• disclosure status.

Reports missing these fields may still be useful, but should be marked as limited confidence.

5. Clarification Questions

Ask only for information needed to proceed safely. Preferred questions:

• What authorization covered the observation?
• Was any third-party data accessed?
• Did testing continue after the issue was identified?
• Can you provide a redacted screenshot or log excerpt instead of raw data?
• What product version or build was observed?
• Has the vendor already been notified?
• Are you requesting anonymity?

Avoid asking reporters to perform additional testing unless authorization is clear and the request is safe.

6. Routing Decisions

Accept for Technical Review

Accept when the report is plausible, evidence is bounded, and PCL can evaluate it safely.

Request Sanitization

Request sanitization when the report contains more sensitive detail than needed but appears to be good-faith and salvageable.

Refer

Refer when another coordinator, vendor, CNA, CERT, platform, or program is better positioned to handle the issue.

Reject

Reject when the report is unsafe, unauthorized, coercive, exploit-focused, unsupported, or outside PCL’s role.

7. Escalation Triggers

Escalate immediately when the report involves:

• active exploitation;
• critical infrastructure;
• safety impact;
• live credentials or secrets;
• bulk personal data;
• ransomware or malware;
• extortion language;
• minors or vulnerable populations;
• legal threats;
• public disclosure deadline within 7 days;
• multiple affected vendors;
• media contact.

8. Triage Record

A triage record should include:

• intake ID;
• date received;
• source channel;
• reporter preference;
• target identity;
• authorization summary;
• evidence classification;
• preliminary severity;
• active exploitation status if known;
• routing decision;
• assigned owner;
• next review date;
• retention decision for attachments.

9. Response Quality

Intake responses should be brief, factual, and careful not to imply authorization. Do not promise outcome, bounty, CVE assignment, publication, safe harbor, or legal protection.