Why a contact card matters
During a suspected cyber incident, an office may still have phones, employees, and access to some systems—but not confidence about what to do next. Staff may disable the wrong device, delete suspicious messages, notify customers too early, or wait while an attacker continues using a compromised account.
A short incident contact card cannot replace an incident-response plan. It is a practical bridge between ordinary operations and a more formal response. Keep one printed copy in a secure location and one copy in a separately accessible business location or account. Do not store the only copy inside the email or file system that may be unavailable.
The card should be reviewed at least twice a year and whenever the business changes its technology provider, insurer, attorney, bank, office manager, or emergency contacts.
Section 1: identify the decision owner
Write down the person who can coordinate the first response. This may be the owner, managing partner, practice administrator, or operations manager.
Record:
- Name and mobile number.
- Backup decision-maker.
- Authority to approve emergency technology work.
- Authority to contact customers, employees, insurers, regulators, or law enforcement.
- Preferred after-hours contact method.
Avoid listing only a job title. People need a name and a working number. Verify the number by calling it during the review.
Section 2: list technical and outside contacts
Include the technology provider or managed service provider, cloud-application support contacts, backup provider, internet provider, cyber-insurance carrier, and incident-response firm if one has been selected.
For each contact, record:
- Company and individual contact.
- Main phone number and emergency number.
- Support hours.
- Account number or customer identifier.
- What information the provider will require before taking action.
- Whether the provider can disable accounts, isolate devices, preserve logs, or restore systems.
Do not rely only on a vendor portal. If the portal uses the compromised identity provider, it may be inaccessible during the event.
Section 3: write the first technical actions
The card should contain instructions that are safe for nontechnical staff. Examples include:
- Do not approve unexpected multifactor prompts.
- Do not click links in suspicious messages.
- Do not delete suspicious email, files, or text messages.
- Do not reconnect a disconnected device without direction.
- If ransomware or destructive activity is visible, disconnect the affected device from network access if the response provider has instructed staff to do so.
- Call the decision owner and technical contact using a known number.
The correct action depends on the event. A suspected mailbox takeover, lost laptop, payment-fraud attempt, and ransomware outbreak may require different containment steps. The card should therefore tell staff who decides—not pretend that one instruction fits every incident.
Section 4: preserve useful evidence
Evidence can help the technology provider, insurer, attorney, and law enforcement understand what happened. Record:
- Date and time the issue was first observed.
- Name of the person who noticed it.
- Affected user, device, application, or vendor.
- Exact wording of suspicious messages or payment requests.
- Screenshots, sender addresses, phone numbers, and transaction details.
- Actions taken before and after escalation.
- Names of people contacted and the time of each contact.
Do not alter suspicious files or forward malicious messages broadly. If a screenshot contains sensitive client or patient information, store it securely and limit distribution.
CISA recommends designating a crisis-response team with responsibilities covering technology, communications, legal matters, and business continuity. The contact card should reflect those roles, even if one person performs several of them in a small office.
Section 5: add reporting and notification prompts
The card should remind managers to consider:
- Cyber-insurance notification requirements.
- Attorney or privacy counsel review.
- Contractual reporting obligations.
- Regulatory or sector-specific notification rules.
- Bank or payment-processor notification.
- Local law enforcement and FDLE reporting.
- CISA reporting or assistance resources when appropriate.
Do not write a universal deadline unless it has been verified for the business’s specific situation. Notification requirements may depend on the type of data, the jurisdiction, the contract, the insurer, and the facts of the event.
FDLE maintains a Cybercrime Office and a route for reporting cybercrime in Florida. That reporting path should be saved as a reference, but it does not replace immediate technical containment or legal advice.
The five-minute test
Ask a staff member who did not create the card to answer these questions:
- Who is the first decision owner?
- What number should be used if email is unavailable?
- Who handles technical containment?
- What evidence must not be deleted?
- Where is the offline copy?
- Who decides whether customers, the bank, insurer, or authorities are contacted?
If the person cannot answer, revise the card. The exercise is successful when a busy employee can find the right people without searching through the potentially affected system.
What this tool can and cannot prove
The card can prove that contacts, responsibilities, and first actions were documented and reviewed. It cannot prove that backups work, that monitoring is effective, that an insurer will cover a loss, or that a provider will respond within a particular time.
Use it alongside a backup restoration test, account-recovery exercise, and tabletop discussion. Treat every exercise as a way to find missing information while the office is calm.
Copy-ready structure
- Incident date and time observed:
- Person reporting:
- Decision owner:
- Backup decision owner:
- Technical provider:
- Cyber-insurance contact:
- Attorney or privacy contact:
- Bank or payment contact:
- Law-enforcement reporting information:
- Systems or accounts affected:
- Evidence preserved:
- Actions taken:
- Next review date:
A small card is not a security program. It is a readiness habit that reduces avoidable confusion when normal communication channels or assumptions cannot be trusted.