What Small Companies Should Do After a Security Incident

An incident is any time confidentiality, integrity, or availability is reasonably in doubt: a key in a public gist, ransomware on an accounts laptop, a storefront serving unexpected script, or an unexplained spike in API token usage. Palmate’s cloud and DevOps advice for small teams is a structured, methodical sequence you can run without a dedicated Security Operations Center (SOC). This is not a guide to investigating other people’s systems, and it is not legal advice.

Prevention lives in access control and secrets hygiene and Linux production baseline. Recovery depends on backups you can restore. When something breaks, your response determines whether you suffer a two-hour credential rotation or a month-long business crisis.

The Small-Team Incident Response Timeline

During an active security event, panic leads to destructive actions—such as rebooting machines, wiping compromised servers before taking forensic snapshots, or discussing credentials in open group chats. Follow a phased timeline:

1. Contain Without Destroying Evidence

The instinct of many founders and engineers is to immediately delete a compromised virtual machine or reboot a server. This wipes volatile memory (RAM), active network socket tables, and attacker command histories that you may need for law enforcement, cyber insurance claims, or regulatory filings.

• Revoke the leaked credential or token immediately. Use the cloud or vendor dashboard directly. Do not wait to deploy code; invalidate the session or API token from the provider management console first.
• Isolate rather than terminate. In AWS, GCP, or Hetzner, remove the compromised instance’s security group and attach an "isolation" group that blocks all inbound and outbound traffic except for a dedicated administrative bastion IP.
• Take the service offline if active customer harm is occurring. If an e-commerce checkout has been injected with a JavaScript keylogger or a skimming script, taking 30 minutes of planned downtime is infinitely cheaper than leaking 5,000 credit card numbers.
• Preserve disk snapshots first. Before you touch any files, take an immediate, read-only snapshot of all attached storage volumes. If the machine was ransomed, disconnect the network cable or virtual NIC immediately to prevent lateral spread across shared network drives.

If payment credentials or sensitive personal information were exposed, paying a ransom is a business and legal decision that rarely guarantees data deletion. Restoring from off-site, immutable backups is the only technically sound path.

2. Systematic Credential and Secret Revocation Sequence

When a leak occurs, attackers rarely stay confined to the single service where the key was exposed. If an AWS access key or SSH private key leaked, assume lateral reconnaissance has already taken place:

1. Root and Cloud Administrative IAM: Immediately rotate administrator passwords, invalidate all active web console sessions across the team, and verify whether new IAM users, access keys, or SSH key pairs were created during the intrusion window.
2. Database and Internal Datastore Credentials: Rotate passwords for application database roles, Redis caches, and read-replicas. Terminate all active connection pools to force every running service to re-authenticate with new credentials.
3. Third-Party Payment and Transactional Webhooks: Invalidate Stripe, PayPal, Razorpay, or payment gateway secret keys and webhook signing secrets. Check payment gateway webhooks to verify an attacker has not quietly added an external endpoint to receive transaction payloads.
4. Third-Party SaaS and Notification Integrations: Invalidate SendGrid, AWS SES, Twilio, or Slack bot tokens. Attackers frequently harvest email and SMS tokens to run phishing campaigns from your legitimate domain reputation.
5. Session and Encryption Keys: Invalidate web application session signing secrets (JWT_SECRET, cookie encryption keys). This forces all active logged-in user sessions across your platform to log out and re-authenticate.

Never paste rotated production secrets into an open Slack or WhatsApp channel to "share with the developers." Distribute them securely using your encrypted secrets manager or password vault.

3. Tell the People Who Must Know

Who you must notify—and the deadline for doing so—is governed by contractual obligations and statutory data privacy laws (such as GDPR, CCPA, or DPDP).

• Legal Counsel and Cyber Insurance: Involve legal counsel before drafting public communications if customer PII, health records, or payment data were accessed. Many cyber insurance policies require notification within 24 to 48 hours of discovery.
• Payment Processors and Acquirers: If credit card data or payment forms were compromised, card brand operating regulations mandate immediate disclosure to your acquiring bank or processor.
• Designate a Single Spokesperson: In a small team, engineering speculation in customer support tickets or social media channels quickly becomes the official public narrative. Route all external communication through a single designated founder or executive.
• Clear, Factual Transparency: When notifying affected users, avoid vague jargon like "we experienced an unauthorized system anomaly." State clearly what happened, what specific data fields were or were not involved, what actions you took to resolve it, and what actions users should take (e.g., password reset, 2FA enrollment). Your privacy policy sets customer expectations; an incident reveals whether your engineering reality matches that policy.

4. Recover from Known-Good Artefacts

Never attempt to "clean" a compromised operating system by manually searching for suspicious files. Attackers routinely install user-space rootkits, modify PAM authentication modules, and establish cron-based backdoors that evade casual inspection.

• Rebuild from scratch: Provision fresh virtual machines or container instances using known-good infrastructure-as-code scripts, clean base images, and verified git commit tags.
• Restore databases to a clean boundary: Restore database state from backups taken prior to the verified compromise timestamp. If you cannot establish when the attacker gained initial access, examine database transaction logs and web server access logs to isolate the earliest suspicious query.
• Verify checksums: Audit your application dependencies and package lockfiles to confirm no malicious third-party dependencies were injected during the incident.

5. The Blameless Post-Mortem Template

An incident is only truly resolved when the architectural vulnerability that permitted it has been permanently eliminated. Write a concise after-action report within 72 hours using this four-part structure:

1. Incident Summary & Timeline: Document exact UTC timestamps for initial intrusion, automated or manual detection, containment actions, and final recovery.
2. Root Cause Analysis: Identify the fundamental technical or organizational breakdown (e.g., hardcoded service key committed to a public repository, lack of mandatory multi-factor authentication on a legacy server, unpatched CMS plugin).
3. Blast Radius & Impact: Detail the exact systems accessed, number of customer records touched, and hours of operational downtime incurred.
4. Action Items (The 48-Hour vs 30-Day Rule):
   • Immediate (48 Hours): Invalidate exposed keys, patch the specific vulnerable component, enforce MFA on all engineering accounts.
   • Structural (30 Days): Migrate static credentials to dynamic IAM roles, implement automated secret scanning in your CI/CD pipeline, and review network security groups.

The website launch checklist serves as an effective operational baseline following a security event: verifying TLS certificates, checking security response headers, testing database backup automation, and restricting administrative panel endpoints.

IT consulting after an incident should focus on structural architectural hardening: zero-trust network boundaries, centralized audit logging, and automated secrets lifecycle management. Palmate helps teams rebuild resilient, production-hardened runtimes so that subsequent security threats are contained automatically.

Authoritative References & Standards

To cross-reference the engineering patterns and regulatory considerations described in this guide, consult the following authoritative industry documentation and RFC standards:

• OWASP Top 10 Web Application Security Risks — Consensus benchmark for critical application vulnerabilities.
• Center for Internet Security (CIS) Linux Benchmarks — Prescriptive configuration guides for establishing secure production baselines.
• NIST Cybersecurity Framework — Standards and guidelines for managing cybersecurity-related operational risk.