A suspected account compromise, exposed customer data, unfamiliar deployment, or ransomware alert can leave a small product team trying to investigate and keep the service running at the same time. A short incident plan helps you avoid rushed changes that erase useful evidence or leave the original access open.
You do not need an enterprise security team to respond in a more organized way. Start by confirming what happened, limiting ongoing harm, preserving the records you may need, and deciding who must be involved. This guide adapts the NIST incident response recommendations in SP 800-61 Rev. 3 for an individual maintainer or small team. It is an operational starting point, not legal advice or a replacement for a qualified incident responder.
What should trigger an incident response?
An unusual alert is a reason to check, not proof that an attacker is present. Possible signals include:
- An administrator account or API credential used in an unexpected way.
- A deployment, configuration change, or new account nobody on the team recognizes.
- A report that private information is visible to the wrong users.
- A hosting, identity, payment, or database provider warning about suspicious activity.
- Data being changed, deleted, encrypted, or exported unexpectedly.
- A service outage with signs that access or data integrity may also be affected.
First check whether a known release, provider outage, scheduled task, or user action explains the signal. If the evidence is unclear but sensitive data or privileged access could be involved, treat it as a suspected incident while you verify. Do not describe a suspicion as a confirmed breach.
The first response: contain, record, and coordinate
The order depends on what is happening. If an account is actively exposing customer records, stopping that exposure takes priority. When possible, preserve important records before making changes that could remove them. NIST's current guidance places incident response within broader cybersecurity risk management; the steps below are a lightweight way to coordinate the immediate work, not a substitute for provider-specific procedures.
1. Assign one incident lead and use a trusted channel
Choose one person to coordinate actions and keep a timeline. If you are working alone, write down decisions as you make them. Use a communication account and device you believe are safe; do not rely on an email account that may itself be compromised.
Record the time and time zone, what alerted you, who took each action, and what changed. Keep confirmed facts separate from assumptions. A simple incident log prevents several helpers from repeating risky changes or losing track of what has already been disabled.
2. Confirm the affected service and likely scope
Check the alert against the systems that produced it: hosting and identity-provider audit logs, deployment history, application events, database activity, and relevant provider notifications. Note:
- Which application, account, environment, or third-party service is involved.
- When the activity may have started and whether it is still happening.
- Which data or user workflows could be affected.
- Which credentials, integrations, or deployments changed around the same time.
Keep the first assessment narrow. A single suspicious login does not establish that every customer record was accessed, and an unavailable service does not by itself establish a security incident. Update the scope as you find evidence.
3. Stop ongoing access with the smallest safe change
Use the affected provider's documented controls. Depending on the evidence, that may mean disabling one account, revoking its active sessions, removing a specific key, pausing a deployment, restricting an exposed route, or temporarily taking a service offline. If you suspect a machine or workload is involved, ask the provider how to isolate or preserve it before deleting or rebuilding it.
Prefer a targeted action that stops the immediate risk without destroying information you still need. If harm is continuing, contain it promptly and record what you changed. Avoid deleting logs, accounts, databases, or virtual machines just to make the alert disappear. Do not make a broad configuration change unless you understand what it will interrupt and how to reverse it.
4. Preserve useful records
Export relevant audit and application logs, deployment records, access alerts, and provider messages before their retention window expires. Keep the originals in a restricted location, note who collected them and when, and work from a copy when practical. If you lack access to logs or are unsure how to preserve a provider-managed system, contact that provider's support rather than guessing.
Logs can contain sensitive information. The OWASP Logging Cheat Sheet advises against directly recording passwords, access tokens, session identifiers, encryption keys, and sensitive personal data. Do not paste secrets or unnecessary customer records into a ticket, chat, or public issue while investigating. Follow your retention and privacy obligations when storing incident material.
Handle common small-app scenarios
These are containment examples, not a forensic procedure. Follow the relevant provider's recovery guidance and get specialist help if the incident is beyond your ability to scope safely.
| What you suspect | A practical first move |
|---|---|
| A hosting or application administrator account was taken over | Disable or secure that account using a trusted device, revoke active sessions, and review recent account, permission, and deployment changes. Check whether other administrators or recovery methods were changed. |
| A database, cloud, or API secret was exposed | Revoke the exposed value and issue a replacement through the provider's control panel. Check where the secret was used, update those consumers, and confirm the old value no longer works. Removing it from the latest code does not revoke a credential that may already have been copied. |
| An unfamiliar release or configuration change appeared | Pause further deployments, preserve the change and deployment history, and compare it with a known-good release. Roll back only when you have checked that the earlier version will not restore the same access path or data problem. |
| Customer information may have been exposed | Restrict the affected access or export path, preserve relevant access records, and identify the kinds of data and users that could be involved. Bring in your provider and qualified legal support before making claims about scope or notification duties. |
| Ransomware or destructive activity is suspected | Isolate affected systems where it is safe to do so, protect backups from further changes, and contact your hosting provider and an incident-response professional. Use the response checklist in CISA's StopRansomware Guide, which specifically addresses ransomware and data extortion. |
Secure accounts and replace credentials carefully
Changing one password or key may not be enough if someone can still control the email, source-code, hosting, or identity account that issues it. From a trusted device, secure the relevant administrator and recovery accounts first, revoke active sessions, and review recent sign-ins and permission changes. Then replace affected application secrets and third-party tokens.
Update every service that uses a replaced secret, including deployments, background jobs, webhooks, and local operational tooling. Keep the new value out of source control, incident notes, and ordinary chat. If you are not sure which systems depend on it, plan a controlled update rather than revoking unrelated credentials and creating a second outage.
For ongoing prevention, see our guide to handling environment variables and secrets in web projects. The response itself should also leave you with an accurate list of which credentials were replaced and where.
Decide what to communicate and when
Write down what is confirmed, what remains unknown, which users or partners might be affected, and when you will review the information again. Tell your hosting, identity, payment, or other relevant providers through their official support channels. A small business may also need to involve an insurer, a lawyer, a client, or a regulator, depending on the service and the data involved.
Notification duties and deadlines vary by jurisdiction, industry, contract, and type of information. Do not assume that one general checklist answers whether or when you must notify people. Get qualified advice promptly when personal, payment, health, or other regulated data may be involved. If you do contact affected users, share verified facts, practical steps they can take, and a reliable way to reach you; avoid speculation about the cause or scope.
CISA recommends that organizations prepare incident and communications plans, including notification procedures, and specifically points to applicable breach-notification laws and legal counsel in its ransomware guidance. That guide is focused on ransomware and data extortion, so use it for those cases rather than treating it as a universal legal reference.
Recover from a known-good state
Do not return a system to service just because it responds to a health check. First address the access or change that caused the incident, then restore or redeploy from a version and backup you have reason to trust. Preserve the affected system or relevant records before rebuilding when possible.
Test recovery in a separate environment if you can. Check that the application starts, users can sign in, essential data is present, and integrations work with the replacement credentials. Review privileged accounts and permissions, confirm backups are still available, and monitor relevant logs and alerts as you restore traffic. A backup may contain the same compromised settings or secrets as the original; follow a tested backup and restore plan instead of assuming that any recent copy is safe.
After recovery, keep a closer watch for repeated access attempts, unfamiliar accounts, unexpected configuration changes, and errors in the affected workflows. A basic health-check and readiness setup can help show whether the application is serving requests, but it does not prove that the system is free of compromise.
Close the incident and improve the runbook
When the immediate issue is stable, write a short review while the timeline is still clear:
- What happened, when it was first noticed, and which systems or users were affected.
- Which containment and recovery actions worked, and which caused delays or side effects.
- What remains uncertain and what evidence supports the current conclusion.
- Which follow-up changes have an owner and a deadline.
The aim is to make the next response easier, not to assign blame or claim certainty you do not have. Improve one or two practical gaps at a time: an account without multifactor authentication, logs that expire too quickly, an untested backup, or an unclear route to provider support. The OWASP Logging Cheat Sheet is a useful reference for deciding which application events to record and how to limit sensitive log data.
Before the next incident, keep an offline copy of a one-page runbook with provider support links, account owners, emergency contacts, backup locations, and the steps for disabling access. Test that you can reach the needed controls and restore a backup. A short practice exercise can reveal missing permissions or stale contact details before a real outage makes them urgent.