Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What information should you give a DFIR firm?
Updated
Hand over assets, logs, access, a UTC timeline, and architecture so DFIR intake can start. Do not wipe, rebuild, or alter hosts first. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response — guidance, not a statute), NIST SP 800-61 Revision 3 (Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile — current final as of April 2025; it superseded SP 800-61r2; guidance, not a statute), SWGDE published digital-evidence best-practice documents (consensus guidelines, not a statute), and RFC 3227 (Guidelines for Evidence Collection and Archiving — IETF BCP 55, a Best Current Practice, not a statute). GDPR Article 5(1)(c) data minimisation and California Civil Code Title 1.81.5 (CCPA/CPRA) are cited for privacy context only — this page is not a determination that either applies. ISO/IEC 27037 is named as a standard of guidelines for identification, collection, acquisition and preservation of digital evidence; it is not a law and the full text is paywalled. This page does not rank DFIR firms, does not name any, does not start a notification clock, does not ship a downloadable intake form, and is not a substitute for counsel, your insurer, or a retained DFIR firm. The preserve-evidence page on this site is the capture list. The never-delete-after-breach page on this site is the anti-list. The chain-of-custody page on this site is the handling record. The questions-to-ask-an-incident-response-provider page on this site is the vendor-call script. The breach-investigation-cost page on this site is the cost-driver explainer. The comparing-major-incident-response-providers page on this site is the named-brand criteria table (not a ranking; inclusion is not endorsement). The best-incident-response-firms page on this site is the inclusion-criteria checklist. A dedicated incident-reporting-deadlines guide is not on this site yet. Not legal advice.
This is an intake checklist, not a ranking and not YOUR legal hold
Audience: an engineering leader, CISO, incident commander, or counsel onboarding a DFIR firm mid-incident who needs to know what to hand over — and what not to touch — so the investigation starts without spoiling evidence. The preserve-evidence page on this site is the capture list. The never-delete-after-breach page on this site is the isolate-don't-destroy anti-list. The first-15-minutes page on this site is the do-not-power-down checklist. The chain-of-custody page on this site is the handling record. The questions-to-ask-an-incident-response-provider page on this site is the vendor-call script. This page is the handover list: assets, logs, access, timeline, architecture, in-scope data classes, and existing tickets, with the do-not-alter cautions that protect those sources. Print this page; the tables are the checklist. It does not rank DFIR firms, does not name any, does not ship a downloadable form, and is not YOUR legal hold. A legal hold is a counsel-directed preservation obligation on YOUR facts. This page is not a substitute for counsel.
NIST SP 800-61r3 is the current final incident-response guidance this page cites — a CSF 2.0 community profile, guidance, not a statute. It superseded SP 800-61r2 in April 2025. Preparation includes knowing how you will engage external parties; intake under duress is the failure mode that preparation is meant to avoid. NIST SP 800-86 is a guide to integrating forensic techniques into incident response — also guidance, not a statute. It assumes trained people, procedures that preserve integrity, and the instruction to consult management and legal counsel before applying the practices. RFC 3227 is IETF BCP 55 — a Best Current Practice, not a statute; volatile first; do not analyse the evidence copy. SWGDE publishes consensus digital-evidence guidelines; they are not a statute and not a ranking of firms. Last verified 7 September 2026. Not legal advice.
- This is an intake checklist, not a ranking, not a vendor list, and not a court order. This page does not rank DFIR firms and does not name any.
- A legal hold (litigation hold) is counsel's document on YOUR facts. An evidence hold is an operational instruction to stop rotation, deletion, reimage, and 'cleanup' until capture and counsel say otherwise. Do not treat this page as YOUR legal hold.
- Counsel-directed DFIR is common practice so working papers can sit under attorney-client privilege and work-product. That is practice, not a ruling that privilege will attach. The contact-breach-counsel page on this site is the privilege-and-engagement checklist.
- Hand over known facts, sources, and access — not a rebuilt host, not a wiped disk, not a 'cleaned' mailbox. Isolate, do not destroy.
- This page does not start a notification clock, does not interpret YOUR policy, does not determine that GDPR or CCPA applies, and is not legal advice.
Do not alter first — wipe, rebuild, patch, and power-off
Do this before you assemble the handover pack. A tidy estate is often an empty one. Wipe, rebuild, premature patching, and power-off without a method destroy the sources a DFIR firm would have used. The never-delete-after-breach page on this site is the prohibition list; this section is the same work stated as intake cautions. Isolate, do not destroy. RFC 3227 and NIST SP 800-86 are guidance, not statute. Last verified 7 September 2026. Not legal advice.
- Volatile first. Memory, live connections, and running processes are gone when power is. Disk waits. Logs wait. Archives wait. RFC 3227: proceed from the volatile to the less volatile.
- Working copy, not the original. Acquire, hash, and examine a duplicate. NIST SP 800-86: collection should preserve the integrity of the data. RFC 3227: make a bit-level copy and do not analyse the evidence copy. The chain-of-custody page on this site is that record.
- Personnel should be trained for the method they are using. NIST SP 800-86: untrained collection is how originals get written. If you cannot image soundly, isolate and wait for the firm — do not improvise a wipe.
- This page does not rank DFIR firms, does not interpret YOUR legal hold, does not start a notification clock, and is not legal advice.
| Do not | What you lose | Kind of claim |
|---|---|---|
| Do not wipe, reimage, restore-over, or 'just rebuild' an affected host | The original disk is overwritten. Persistence, deleted files, timestamps, and the sample itself are gone. Investigators inherit a clean box and a story. | NIST SP 800-86: collection should preserve integrity — guidance, not a statute. NIST SP 800-61-class handling puts preservation before eradication. Reimaging is eradication. Image first. |
| Do not patch, upgrade, or 'harden' the evidence host as the first move | A patch overwrites binaries, configs, and sometimes logs. The pre-patch state is what the examiner needed. Containment can be isolation (VLAN, security group, cable) without changing the box. | Best practice / SRM recommendation on this page: isolate, then capture, then eradicate. A patch on a working copy after imaging is a later timebox. Not a statute. |
| Do not power off a live host without a method and a recorded reason | Volatile memory is gone: encryption keys, fileless malware, live sessions, the process table. A later disk image cannot reconstruct that row. | RFC 3227 order of volatility (IETF BCP 55 — teaching sequence, not a statute): memory before disk. NIST SP 800-86 treats live acquisition as a trained method. Document the gap if you cannot isolate any other way. |
| Do not rotate, truncate, or delete logs (auth, cloud, network, endpoint, mail) | Those logs are how you later show who did what, when. Rotation is deletion on a timer. A tidy SIEM is an empty window. | RFC 3227 lists remote logging after disk because it lasts longer than RAM — not forever. Place the hold now. Standards-body guidance, not a court order. |
| Do not 'clean up' malware samples, persistence, or suspicious files before they are imaged | The sample, the path, the hash, and how it got there are the case. AV 'clean and delete' on the original is eradication dressed as hygiene. | NIST SP 800-86-class method: capture first. Eradication is later. FTC Data Breach Response guidance: do not destroy forensic evidence — regulator guidance, not a statute. |
Four kinds of claim — do not mix them
A legal hold, a NIST guide, a SWGDE best-practice document, and an SRM recommendation are not the same kind of claim. This page keeps them apart. Last verified 7 September 2026. Not legal advice.
| Kind of claim | What it is | What this page does with it |
|---|---|---|
| Legal-hold obligation | A counsel-directed duty to preserve potentially relevant information for a matter that actually applies. Litigation hold, regulatory preservation, and insurer-notice conditions are legal and contract questions on YOUR facts. This page is not YOUR legal hold and not a court order. | Cited so you do not confuse an intake checklist with counsel's hold. Counsel owns the hold language, the scope, and the channel. Not legal advice. |
| Standards-body guidance | NIST SP 800-86 (guide to integrating forensic techniques into IR — guidance, not a statute). NIST SP 800-61 Revision 3 (IR recommendations as a CSF 2.0 community profile — guidance, not a statute; superseded SP 800-61r2 in April 2025). ISO/IEC 27037 (guidelines for identification, collection, acquisition and preservation of digital evidence — a standard of guidelines, not a law; the full text is paywalled). | This page teaches the handling those documents describe. A guide or a standard of guidelines is not a statute and not YOUR legal hold. |
| Best practice | RFC 3227 is IETF BCP 55 — Guidelines for Evidence Collection and Archiving. Teaching order of volatility; make a bit-level copy; do not analyse the evidence copy. SWGDE publishes consensus digital-evidence best-practice documents. Neither is a statute. | Used as practitioner method. A Best Current Practice is not a legal duty. SWGDE is not a ranking of firms. |
| SRM recommendation | What this page tells you to hand over and not to alter: assets, logs, access, UTC timeline of known facts, architecture, in-scope data classes, existing tickets; do not wipe, rebuild, patch, or power-off without a method. The product does not image hosts, keep a chain of custody, or export a handover pack. | Our operational recommendation, not a legal duty, not a product feature, and not a ranking. Record the hold where YOUR procedure says — paper, a counsel-held log, the DFIR firm's system. |
Printable intake table — what to hand over
Hand over what the firm needs to start, on the out-of-band channel counsel names. Known facts, not hypotheses dressed as findings. Minimize what you copy; the privacy section below is the PII caution. This table is a checklist you can print. It is not a downloadable form this product ships, not a ranking, and not YOUR legal hold. Last verified 7 September 2026. Not legal advice.
| Item | Why it matters | Do-not-alter note |
|---|---|---|
| Assets / inventory | Named hosts, VMs, cloud accounts and tenants, SaaS apps, identity providers, and network segments that may be in scope. A DFIR firm cannot image what it cannot find. An asset list is a starting map, not a finding that those assets were compromised. | Do not rebuild or decommission listed hosts to 'get them off the list.' Isolate. Leave powered on unless a trained handler records why power-off was the only isolation left. |
| Logs — authentication / identity | IdP, SSO, VPN, directory, privileged-access, and failed-login rows. Who authenticated, from where, and when is often the first reconstructable timeline. | Do not rotate, truncate, or 'tidy' failed-login noise. Place the hold on the log store. Export a copy; do not delete the source. |
| Logs — cloud | Control-plane and data-plane audit logs (API calls, IAM changes, storage access, new resources). Cloud logs roll off. The cloud-account-compromise-checklist page on this site is the preserve-cloud-logs-first runbook. | Do not disable logging, shorten retention, or overwrite the trail to 'save cost' mid-incident. Snapshot / export first. Provider consoles change; name the service and the time window in UTC. |
| Logs — network | Firewall, DNS, proxy, VPN concentrator, flow, and packet captures if you already have them. Egress is how exfiltration is later shown or not shown. The was-data-stolen page on this site is that determination — this row is the source, not the conclusion. | Do not overwrite ring buffers before export. Do not 'tune' the sensor so the interesting flows disappear. Capture, then filter on a working copy. |
| Logs — endpoint / EDR / host | EDR telemetry, local event logs, scheduled-task and service changes, and any already-collected memory or disk images. Say what you have imaged and what you have not. | Do not reimage the endpoint to 'get EDR healthy.' Do not run a full cleanup on the original. Isolate. Hand the existing image with hashes if you have them. |
| Access path | How the firm will reach the estate: jump host, VPN, break-glass, cloud console, identity-provider admin, out-of-band comms. Named people who can grant that access. The who-to-call page on this site is the contact map. | Do not recycle the compromised admin so the firm 'cannot be locked out' — disable, then grant a new, scoped, logged path counsel and the commander name. Do not share standing domain-admin in chat. |
| Timeline of known facts | UTC times, who observed what, which systems, which tickets. Separate observed fact from hypothesis. The incident-timeline page on this site is the UTC discipline. A Slack dump is not a timeline. | Do not backfill a prettier story. Do not delete the contemporaneous notes because they look messy. The messy log is the evidence of when you knew. |
| Architecture / network diagram | How the estate is actually wired: identity plane, prod vs corp, cloud accounts, trust boundaries, logging sinks. A current diagram beats a slide from last year's audit. | Do not 'fix' the diagram to match policy mid-incident. Mark known-stale. Do not change routing or peering to match the picture until capture exists. |
| In-scope data classes | What kinds of data those systems hold — credentials, customer records, payment, health, source code, models — as YOUR classification, not a legal conclusion. Scope is how the firm sizes capture and who must be in the room. | Do not dump the data itself into the intake pack. Name the class and where it lives. Bulk export of personal data is a counsel and DPA question — see the privacy section. |
| Existing tickets, chat, and mail about THIS incident | The IR ticket, the first alert, the bridge notes, the change tickets that might be related. Examiners reconstruct 'when did you know' from these as much as from host images. | Do not purge the mailbox, recycle the chat channel, or 'clean' the ticket so it looks professional. Export, then hold. Legal-hold language is counsel's. |
Privacy caution — minimize PII; DPA before bulk log export
Intake is not a licence to dump every mailbox, HR file, and customer export into the firm's share. Minimize what you share. Name data classes and point at sources; let counsel and the firm pull what the method actually needs. This page is not a determination that GDPR or CCPA applies to YOU. Last verified 7 September 2026. Not legal advice.
- Minimize personal data in the intake pack. A user-id and a timestamp often suffice where a full HR row does not. GDPR Article 5(1)(c) states personal data shall be adequate, relevant, and limited to what is necessary in relation to the purposes — data minimisation. That is a principle in Regulation (EU) 2016/679, not a finding that GDPR applies to YOUR incident.
- Before a bulk log or mailbox export that includes personal data, counsel should have processor / service-provider terms in place with the firm (a DPA in GDPR language; a service-provider contract in CCPA/CPRA language). GDPR Article 28 is the processor-contract article. California Civil Code Title 1.81.5 (the CCPA, as amended) is the California statute this page names for context. Neither citation is a determination that the statute applies.
- Counsel directs the channel. Do not drop a customer database into a consumer file-share 'so they can start.' Out-of-band, access-controlled, and on the path counsel names. The contact-breach-counsel page on this site is that checklist.
- Redact where YOU can without destroying the forensic value of the source. Redact a working copy or an intake extract — not the original evidence store. NIST SP 800-86: preserve integrity of the data you may later need to examine.
- This page does not draft YOUR DPA, does not decide lawful basis, does not start a notification clock, and is not a substitute for counsel or your DPO / privacy lead.
Decision tree — counsel-directed versus IT-ordinary-course
Walk top to bottom with the commander and counsel before you hand a bulk pack to anyone. Privilege and work-product are legal questions on YOUR facts. Counsel-directed collection is common practice so working papers can sit under attorney-client privilege and work-product; that is practice, not a ruling that privilege will attach. Dual-purpose ordinary-course IT work is a known waiver risk. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| Has counsel retained and directed the DFIR firm, with a SOW that says the work is to assist counsel in giving legal advice? | Common practice. Hand the intake on the out-of-band channel counsel names. Limit the copy list. The contact-breach-counsel page on this site is the privilege-and-engagement checklist. Confirm with counsel before you upload. | Do not assume privilege will attach after the fact. Dual-purpose ordinary-course IT work — 'we sent the logs so ops could fix it' — is a known waiver risk. That is practice, not a ruling. Pause and call counsel. Not legal advice. |
| Is this a legal hold counsel has already issued, or only an operational evidence hold? | Follow counsel's hold: scope, custodians, sources, and the channel. This page does not replace that document. The intake table still applies as a starting list counsel can adopt or narrow. | Place an operational evidence hold anyway: stop wipe, rebuild, patch-as-cleanup, power-off-without-method, and log rotation. Then get counsel on the bridge. An evidence hold is not a court order and not YOUR legal hold. |
| Will the pack include personal data (mailboxes, HR, customer records, verbose auth logs with identifiers)? | Minimize. Confirm DPA / processor / service-provider terms before bulk export. Counsel owns the channel and the scope. GDPR and CCPA citations on this page are context, not a determination that either applies. | Still minimize. Architecture, asset lists, and UTC facts rarely need a customer dump. Do not add PII 'in case they want it.' |
| Are you about to wipe, rebuild, patch, or power off so the firm 'has a clean box to land on'? | Stop. That is the failure mode this page exists to prevent. Isolate instead. The never-delete-after-breach page on this site is the anti-list. The preserve-evidence page on this site is the capture order. | Good. Continue the intake table. Hand over what you have and what you have not captured — honestly. |
What you need to do now
Order is the failure mode. Rebuilding the host, then writing a timeline, then calling the firm, is the reverse of common practice. The sequence below is practice, not a statute. Last verified 7 September 2026. Not legal advice.
- Stop altering. Do not wipe, rebuild, patch as cleanup, power off a live host without a method, rotate logs, or purge mailboxes. Isolate. The never-delete-after-breach page on this site is that anti-list. The first-15-minutes page on this site is the do-not-power-down checklist.
- Preserve volatile evidence if a trained handler can do it soundly; otherwise isolate and wait. The preserve-evidence page on this site is the order-of-volatility checklist. The chain-of-custody page on this site is the handling record.
- Call counsel. Counsel-directed engagement is common practice. The contact-breach-counsel page on this site is the privilege-and-engagement checklist. The who-to-call page on this site is the contact map. The we've-been-breached page on this site is the first-moves hub.
- Print this page. Fill the intake table: assets, auth/cloud/network/endpoint logs, access path, UTC timeline of known facts, architecture, in-scope data classes, existing tickets. Say what you have already imaged and what you have not.
- Minimize PII. Confirm DPA / processor terms before bulk log or mailbox export. Counsel directs the channel. This page is not a determination that GDPR or CCPA applies.
- The questions-to-ask-an-incident-response-provider page on this site is the vendor-call script. The how-to-select-a-dfir-provider page on this site is the selection decision tree. The best-digital-forensics-firms page on this site is the criteria checklist (not a ranking).
- The breach-investigation-cost page on this site is the cost-driver explainer. The comparing-major-incident-response-providers page on this site is the named-brand criteria table (not a ranking; inclusion is not endorsement). The best-incident-response-firms page on this site is the inclusion-criteria checklist. A dedicated incident-reporting-deadlines guide is not on this site yet. This page does not rank firms, does not name any, and does not start a notification clock.
Glossary
Terms as this page uses them. Where a source names the idea, the kind of source is in the third column so a guidance document is not mistaken for a statute. Last verified 7 September 2026.
| Term | Meaning on this page | Kind of source |
|---|---|---|
| Intake | The information you hand a retained DFIR firm so work can start: assets, logs, access, timeline, architecture, data classes, tickets — plus what you have already captured and what you have not. | SRM recommendation on this page. Not a form this product ships. Not a ranking of firms. |
| Evidence hold | An operational instruction to stop rotation, deletion, reimage, premature patching, and 'cleanup' on named sources until capture and counsel say otherwise. | Practitioner usage on this cluster (first-24-hours page). Not a court order. Counsel owns legal-hold language. |
| Legal hold | A counsel-directed preservation obligation for a matter that actually applies. Scope, custodians, and duration are legal questions on YOUR facts. | Legal duty on YOUR facts. This page is not YOUR legal hold and not legal advice. |
| Order of volatility | Capture the most perishable sources first: memory and live state before disk, then logs, then archives. | RFC 3227 (IETF BCP 55 — Best Current Practice, not a statute). NIST SP 800-86 live acquisition (guidance). |
| DPA / processor terms | The contract under which a firm processes personal data for you. Confirm it before bulk log or mailbox export that includes personal data. | GDPR Article 28 (processor) and CCPA/CPRA service-provider terms — cited for context. Not a determination that either applies. |
| Data minimisation | Share what is needed for THIS intake, not every store you have. Name classes and point at sources; do not dump HR or customer tables 'in case.' | GDPR Article 5(1)(c) (principle in Regulation (EU) 2016/679). Context, not a finding that GDPR applies. |
| Working copy | The duplicate you examine so the original stays unchanged. Hashes of original and copy should match at acquisition. | NIST SP 800-86 collection / examination (guidance). RFC 3227: do not analyse the evidence copy. |
| Chain of custody | The chronological record of who handled the evidence, when, where, how, why, and where it was stored, including every transfer and the hashes. | NIST SP 800-86 (guidance). The chain-of-custody page on this site is that record. This product does not keep one. |
Where this shows up in ShipReady Metrics
This product does not keep a chain of custody. The signed-in app does not image hosts, keep a chain of custody, produce a forensic report, retain a DFIR firm, or export a handover pack to a DFIR vendor. It does not rank forensic vendors and does not ship a downloadable intake form. If you already have a session: signed-in app → Compliance → evidence artifacts / evidence review is control-mapped collection and review for SOC 2 / ISO 27001-style programs — a timestamped evidence record for controls, not a host image and not a forensic chain of custody. The obligation map (frameworks you have marked in-scope) is under Compliance. The cyber risk register lives under Security. Repo inventory lives on signed-in Repositories. AI inventory and governance posture live under Compliance → AI governance. Open findings, remediation status, and KEV/EPSS ranking live on Security findings. Those inventories and evidence rows can be in-scope context a DFIR firm requests — they are not a handover pack, they do not preserve volatile evidence, and they are not a chain of custody. signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a forensic exam, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. ShipReady Passport is a shareable posture snapshot some teams hand a provider during scoping; it is not a DFIR onboarding pack and not a substitute for the intake the firm will still run. None of those surfaces preserves volatile memory, images a disk, or substitutes for the commander, counsel, the insurer, or DFIR.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
NIST SP 800-86 (August 2006), Guide to Integrating Forensic Techniques into Incident Response, remains the current final guide this page cites for collection that preserves integrity, working copies, hashes, trained personnel, live acquisition, and chain of custody — guidance, not a statute, last verified still final on 7 September 2026. NIST SP 800-61 Revision 3 (April 2025), Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, is the current final this page cites — guidance, not a statute; it superseded SP 800-61r2; preparation includes establishing relationships with external parties before an incident. RFC 3227 (February 2002), Guidelines for Evidence Collection and Archiving, is IETF BCP 55 — a Best Current Practice, not a statute; order of volatility; make a bit-level copy and do not analyse the evidence copy. SWGDE publishes consensus digital-evidence best-practice documents for collection, acquisition, and examination; they are not a statute and not a ranking of firms. ISO/IEC 27037 is a standard of guidelines for identification, collection, acquisition, and preservation of digital evidence; it is not reproduced here, is not a law, and the full text is paywalled. Regulation (EU) 2016/679 (GDPR) Article 5(1)(c) (data minimisation) and Article 28 (processor) are cited for privacy context only — this page is not a determination that GDPR applies. California Civil Code Title 1.81.5 (CCPA, as amended by the CPRA) is cited for service-provider / reasonably-necessary-and-proportionate context only — this page is not a determination that CCPA applies. The FTC Data Breach Response guide is US regulator guidance: do not destroy forensic evidence; that is regulator guidance, not a statute. CISA incident-response playbooks include capturing forensic images as part of containment and investigation — operational procedures, not a ranking of firms.
Frequently asked questions
What information should you give a DFIR firm?
Hand over an asset inventory, auth/cloud/network/endpoint logs, an access path, a UTC timeline of known facts, an architecture or network diagram, in-scope data classes, and existing tickets — plus what you have already imaged and what you have not. Do it on the out-of-band channel counsel names. Do not wipe, rebuild, or alter hosts first. This page is an intake checklist, not a ranking. Not legal advice.
What should you not touch before DFIR arrives?
Do not wipe, reimage, rebuild, patch as cleanup, power off a live host without a method, rotate or delete logs, purge mailboxes, or 'clean up' malware samples before they are imaged. Isolate, do not destroy. RFC 3227 is the teaching order of volatility; NIST SP 800-86 is guidance, not a statute. The never-delete-after-breach page on this site is the anti-list. Not legal advice.
Is this a legal hold?
No. A legal hold is a counsel-directed preservation obligation on YOUR facts. An evidence hold is an operational instruction to stop rotation, deletion, reimage, and cleanup until capture and counsel say otherwise. This page is an intake checklist, not YOUR legal hold, not a court order, and not a substitute for counsel. Not legal advice.
Do we need a DPA before sending logs?
If the export includes personal data, counsel should have processor or service-provider terms in place before a bulk send. GDPR Article 28 and CCPA/CPRA service-provider language are cited for context; this page is not a determination that either applies. Minimize PII. Counsel directs the channel. Not legal advice.
Does ShipReady Metrics export a handover pack to a DFIR firm?
No. This product does not image hosts, keep a chain of custody, produce a forensic report, retain a DFIR firm, or export a handover pack. It does have Compliance → evidence artifacts / evidence review, an obligation map under Compliance, a cyber risk register under Security, repo / AI / vuln inventories, and Compliance → CRA reporting (the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for CRA-in-scope findings). Those can be in-scope context a firm requests — not a handover pack and not volatile-evidence preservation. ShipReady Passport is a shareable posture snapshot, not a DFIR onboarding pack. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from NIST SP 800-86, NIST SP 800-61r3, SWGDE best-practice documents, and RFC 3227 (IETF BCP 55). Whether a legal hold applies, whether privilege attaches, whether GDPR or CCPA applies, whether a notification duty applies, and which firm to retain are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.