Data Handling Standard

1. Purpose

Security research often produces evidence that is useful to defenders and dangerous when mishandled. This standard defines how PCL handles vulnerability reports, artifacts, screenshots, logs, traces, correspondence, metadata, and publication drafts.

The goal is to retain enough information to support accurate coordination while reducing exposure of sensitive data, exploit detail, vendor-sensitive information, and personal information.

2. Scope

This standard applies to:

• external reports submitted to PCL;
• internal case notes;
• screenshots, videos, logs, traces, and packet captures;
• vendor or maintainer correspondence;
• public advisories and reports;
• supporting datasets;
• site content and public repository material;
• local-first tools hosted by PCL;
• archived publication records.

This public website repository must not contain raw sensitive evidence.

3. Data Classes

3.1. Public

Material intentionally published on pclsecurity.com or in public repositories.

Examples:

• final advisories;
• final reports;
• public policy documents;
• sanitized examples;
• public aggregate data;
• templates;
• local-only browser tools.

Handling rule: publish only after release review.

3.2. Coordination Restricted

Material needed to coordinate with a vendor, maintainer, reporter, CERT, or affected party but not intended for public release.

Examples:

• reporter contact details;
• vendor correspondence;
• draft timelines;
• non-public remediation status;
• limited reproduction context;
• unapproved severity analysis;
• internal case notes.

Handling rule: restrict to personnel with case need.

3.3. Sensitive Evidence

Material that could harm users, vendors, researchers, or the public if mishandled.

Examples:

• credentials, secrets, keys, tokens, cookies, session identifiers;
• personal data;
• customer or patient records;
• private communications;
• proprietary source code;
• production database content;
• internal network details;
• exploit-like steps;
• screenshots containing non-public records.

Handling rule: minimize, encrypt, segregate, review, and delete when no longer necessary.

3.4. Prohibited Public Material

Material that must not be published by PCL absent exceptional written approval and legal review.

Examples:

• working exploit code;
• live credentials or secrets;
• private user data;
• unredacted production records;
• instructions enabling unauthorized access;
• private vulnerability correspondence;
• data obtained outside authorization;
• identities of reporters requesting anonymity.

4. Collection Rules

4.1. Minimum Necessary

Collect only what is needed to establish:

• affected asset or component;
• observed behavior;
• impact;
• authorization basis;
• evidence confidence;
• coordination status;
• remediation or mitigation status.

Do not collect additional examples simply to prove scale when one minimized example is enough.

4.2. Stop-On-Sensitive-Data Rule

If sensitive data appears, stop the activity that produced it. Preserve the lowest-risk description sufficient to report the exposure. Do not search for additional records, enumerate affected users, download bulk data, or expand access.

4.3. Preferred Substitutions

Replace raw sensitive evidence with safer substitutes whenever possible:

Raw evidence	Preferred substitute
Credential value	Redacted prefix/suffix plus hash
User record	Synthetic equivalent
Database row	Field list and redacted sample
Full screenshot	Cropped and redacted screenshot
Packet capture	Extracted metadata and timestamps
Raw source file	Relevant function name and line reference, if lawful
Internal hostname list	Count and category summary
Private correspondence	Coordination status summary

5. Access Control

Sensitive evidence should be accessible only to people who need it for a case-specific function:

• technical validation;
• evidence review;
• vendor coordination;
• legal or ethical review;
• final publication review.

Access should be removed when the case function ends.

Do not use public issue trackers, shared chat channels, unencrypted email, public paste services, or public repositories for sensitive evidence.

6. Storage Requirements

Sensitive case material should be stored in a segregated location with appropriate access controls and encryption. Public website content should remain separate from raw case material.

Do not store:

• private keys;
• plaintext credentials;
• live session tokens;
• unredacted user data;
• unnecessary full packet captures;
• unnecessary source archives;
• mass export files;
• exploit payloads;
• malware samples;
• unrelated vendor data.

7. Transmission Requirements

Sensitive submissions should be encrypted in transit. PCL publishes a PGP key for sensitive email submissions.

When sending material to vendors or coordinators:

• send the minimum evidence needed;
• use the vendor’s preferred secure channel when available;
• avoid attachments when a safer summary is sufficient;
• strip metadata from images and documents;
• avoid forwarding reporter identity without consent unless necessary;
• document what was shared and why.

8. Redaction Standard

Redaction must remove the sensitive value, not merely obscure it visually when the underlying data remains extractable.

Before publication, remove or neutralize:

• EXIF metadata;
• hidden document text;
• comments and tracked changes;
• clipboard remnants;
• source-map references;
• credentials in URLs;
• authorization headers;
• cookies;
• session IDs;
• internal ticket IDs when not needed;
• personal names and email addresses when not approved for publication;
• precise internal hostnames or IP addresses when not necessary.

9. Retention Posture

PCL retains public artifacts for stable reference. Sensitive case material should be retained only as long as necessary for validation, coordination, publication review, dispute handling, or legal obligations.

A case should identify a retention decision at closure:

• retain sanitized public artifact;
• retain restricted coordination summary;
• delete sensitive evidence;
• preserve minimal audit record;
• preserve under legal or safety hold.

10. Publication Readiness

A document is not ready for publication until review confirms:

1. no credentials, secrets, tokens, or keys;
2. no unnecessary personal data;
3. no private customer data;
4. no exploit-ready instructions;
5. no unapproved reporter identity;
6. no unapproved vendor-sensitive coordination detail;
7. no misleading severity claim;
8. no accidental authorization language;
9. all links and metadata are stable;
10. publication status is clear.

11. Public Repository Rule

The public website repository is a publication surface, not a case-management system. It may contain:

• final public pages;
• sanitized examples;
• templates;
• policy documents;
• local-first tools;
• public data schemas;
• build and validation code.

It must not contain raw reports, reporter correspondence, sensitive evidence, private vendor communications, draft exploit material, or unpublished coordinated findings.

12. Incident Response

If sensitive material is accidentally committed, published, or transmitted improperly:

1. stop further distribution;
2. preserve enough metadata to understand exposure;
3. remove or revoke exposed material where possible;
4. rotate affected secrets when applicable;
5. notify affected parties when appropriate;
6. document root cause;
7. update controls to prevent recurrence.

Do not rely on git history rewriting alone as a complete remediation for exposed secrets. Treat exposed credentials as compromised.

Authorization Boundary

Only the responsible system owner can authorize testing of a third-party system. PCL review, coordination, or publication does not create or expand that authorization.