You just discovered your system has been compromised. Maybe a customer reported unauthorized access to their account. Maybe you found unfamiliar database queries in your logs. Maybe your cloud bill spiked 10x overnight because someone is mining cryptocurrency on your servers. Whatever the signal, the clock is now ticking. Here is exactly what to do in the first 48 hours after a security breach.
Hour 0 to 2: Contain the Damage
The first priority is stopping the bleeding. Not investigating, not communicating, not fixing. Containing.
Revoke compromised credentials immediately. If you suspect API keys, database passwords, or access tokens are compromised, rotate them now. Every minute those credentials remain active is a minute the attacker can use them. This includes: database passwords, API keys for third party services (Stripe, SendGrid, AWS), JWT secrets, OAuth client secrets, and any service account credentials.
Isolate affected systems. If one server is compromised, assume the attacker may have moved laterally. Restrict network access to and from the compromised system. Do not shut it down yet because you need it for forensics, but cut its ability to communicate with other systems.
Preserve evidence. Before you start cleaning up, take snapshots of everything: server disk images, database backups, log files, and network flow data. If this breach leads to legal action or regulatory reporting, you will need this evidence. Deleting or modifying it, even accidentally, can create legal liability.
Activate your incident response team. If you have one. If you do not, identify who is going to lead this response. You need someone making decisions, someone investigating, and someone handling communications. These should not all be the same person.
Hour 2 to 8: Investigate
Once containment is in place, figure out what happened. You need to answer four questions:
How did they get in?
The most common attack vectors we see in web applications:
- Exposed credentials in code repositories. API keys, database passwords, or .env files committed to GitHub. Automated bots scan public repositories continuously and exploit exposed secrets within minutes. Check our web app security checklist for prevention measures.
- SQL injection or insecure API endpoints. Input that is not properly sanitized allows attackers to execute arbitrary database queries or access unauthorized data. Proper API design prevents this.
- Compromised third party dependencies. A package in your supply chain was compromised, and its malicious code now runs in your application.
- Weak or reused passwords. An admin account with "password123" or credentials reused from a previous breach.
- Misconfigured cloud resources. S3 buckets set to public, database ports exposed to the internet, or overly permissive IAM roles.
What did they access?
Check database query logs, API access logs, and file access logs. Look for: bulk data exports, queries against user tables or payment information, creation of new admin accounts, and access patterns that do not match normal usage (3 AM queries from an IP in a country where you have no users).
What did they change?
Compare current system state to your last known good backup. Look for: new user accounts (especially admin accounts), modified application code or configuration, new scheduled tasks or cron jobs, changed DNS settings or email routing rules, and modified access control policies.
Are they still in?
Check for persistence mechanisms: new SSH keys, modified startup scripts, unauthorized OAuth applications, API keys you did not create, and new webhook endpoints. Attackers who gain access often install multiple backdoors so they can return even after you close the initial entry point.
Hour 8 to 24: Communicate
This is the part most companies get wrong. The instinct is to stay quiet until you know everything. That instinct will make things worse.
Notify affected users. If personal data was accessed, users need to know. Be specific about what was exposed and what was not. "An unauthorized party accessed email addresses and hashed passwords. Payment card numbers were not exposed because we do not store them. We have reset all passwords as a precaution." Vague statements like "a security incident occurred" erode trust more than honest specifics.
Check your legal obligations. Depending on your jurisdiction and the type of data involved:
- GDPR requires notification to your supervisory authority within 72 hours if personal data of EU residents was exposed
- CCPA requires notification to affected California residents
- HIPAA requires notification within 60 days for health data breaches
- PCI DSS requires notification to your payment processor if cardholder data was compromised
- Many US states have their own breach notification laws with varying timelines
If you are unsure, consult a lawyer who specializes in data privacy. The cost of legal advice is negligible compared to the cost of a compliance violation.
Notify your cloud provider. AWS, Google Cloud, and Azure all have abuse and incident response teams. They can help identify compromised resources and provide forensic data you might not have access to otherwise.
Do not speculate publicly. Share what you know, not what you think might have happened. Update your communication as you learn more.
Hour 24 to 48: Remediate and Harden
Now you fix things. Not just the vulnerability that was exploited, but the systemic weaknesses that allowed it.
Close the attack vector. If the entry point was an exposed API key, rotate it and remove it from your codebase. If it was a SQL injection vulnerability, fix the vulnerable query and audit every other query in the application. If it was a compromised dependency, update it and audit your dependency tree.
Rebuild compromised systems from scratch. Do not try to "clean" a compromised server. You cannot be sure you found every backdoor. Instead, provision new infrastructure from your infrastructure as code templates, deploy your application from a verified clean build, and restore data from a pre breach backup.
Implement the controls that should have been there.
- Multi factor authentication on all admin and developer accounts
- Secret management using a vault service, never in environment variables or code
- Network segmentation so a compromised web server cannot reach your database directly
- Automated security scanning in your CI/CD pipeline to catch vulnerabilities before deployment
- Principle of least privilege for every service account, API key, and user role
Our cloud and DevOps team sets up these controls as standard practice on every project. They are not expensive to implement, but they are expensive to skip.
Preventing the Next Breach
Getting hacked once is a crisis. Getting hacked twice the same way is negligence. After the immediate response, invest in:
Regular security audits. Not annual compliance checkboxes, but actual penetration testing by people who think like attackers. Quarterly at minimum for applications that handle user data or payments.
Monitoring and alerting. You should know about suspicious activity within minutes, not days. Unusual login patterns, bulk data access, privilege escalations, and configuration changes should all trigger alerts.
Incident response planning. Write down the playbook now while the pain is fresh. Who gets called? What gets shut down? Where are the backups? How do we communicate? Having this documented before the next incident turns a crisis into a process.
Security training for your development team. Most breaches exploit basic vulnerabilities that developers should know how to prevent. Input validation, parameterized queries, proper secret management, and secure authentication flows are not advanced topics. They are fundamentals.
You Do Not Have to Handle This Alone
A security breach is overwhelming, especially if your team does not have deep security experience. We have helped companies respond to active breaches, harden their systems after incidents, and build security practices that prevent future compromises. Whether you need a full security audit and rebuild or a focused consulting engagement to assess your current posture, having experienced people in the room changes the outcome.
The difference between a dedicated development partner and an offshore team during a security incident is response time and accountability. When your system is compromised at 2 AM, you need a team that answers the phone.
If you are dealing with a breach right now or want to make sure you are prepared for one, contact us immediately.