Incident response without an in-house team: how a startup prepares and reacts

The startup reality: no SOC, no CSIRT, real risk

The vast majority of Brazilian startups reach dozens of employees — and sometimes hundreds — without a single professional dedicated to information security. The engineering team takes care of the product, the CTO handles all of the infrastructure, and the founder signs the security SaaS contract that no one reads. This setup is not irresponsibility: it is the financial and prioritization reality of a company that is growing.

The problem is that attackers know this reality. Ransomware groups, infostealer operators, and targeted phishing actors choose victims precisely for the size of their attack surface combined with the absence of detection. A 30-employee fintech processes payments, stores personal data, and has access to banking APIs — from a risk standpoint, it is as attractive as a larger company but offers far less resistance.

The good news is that minimum viable preparation does not require hiring a CISO right away. It requires a decision, documentation, and a few technical controls that any CTO can implement in under a week. What does not work is waiting for the incident to happen before thinking about the subject.

Minimum viable preparation before an incident

The starting point is a simple incident response plan: a document of at most two pages that answers four questions — who decides to declare an incident, who notifies whom, where the emergency credentials are, and what the priority order of actions is. This document must exist on paper or in an offline system that is accessible even if the main environment is compromised.

MFA on every account with privileged access is not optional. Cloud accounts, code repositories, payment platforms, and corporate email with MFA eliminate most of the initial access vectors that lead to serious incidents. Hardware tokens offer the strongest protection; TOTP apps are acceptable; SMS is not.

Tested immutable backups deserve special emphasis. Immutable means the backup cannot be altered or deleted by compromised credentials — most cloud providers offer immutable retention policies at low cost. Tested means someone performed a full restore and confirmed that it works. A backup that has never been restored does not exist from an operational standpoint.

Centralized logs in a destination separate from the main environment are the difference between an effective forensic investigation and an exercise in speculation. Tools like AWS CloudTrail, Google Cloud Audit Logs, or a lightweight SIEM are enough for early-stage startups. The fundamental requirement is that the logs cannot be deleted by whoever compromised the operational environment.

An IR retainer — a prior contract with a company specialized in incident response — ensures that, when the incident happens, you will have professionals available in hours, not weeks, and at a cost agreed in advance. Hiring IR on an emergency basis without a retainer costs between two and five times more and often involves days of waiting for a team to be allocated.

The NIST SP 800-61 cycle adapted for a small team

NIST SP 800-61 defines six phases of incident response that work regardless of team size: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity. In a startup, each phase may have one or two people in charge instead of an entire team, but the logical structure holds.

Detection and Analysis begins with an alert — a user reporting odd behavior, an alarm from a monitoring tool, or an external notification like the one CERT.br sends when it detects malicious activity associated with your ASN. The initial analysis has one central question: is this a real incident or a false positive? Preserve the evidence before taking any action — screenshots, logs, timestamps. Do not reboot systems before capturing the state.

Containment has two distinct moments. Short-term containment isolates the problem immediately: disconnecting a compromised host from the network, revoking exposed credentials, blocking a malicious IP. Long-term containment sets the stage for operating in a degraded mode while the investigation advances — without destroying evidence or disrupting the business more than necessary.

Eradication removes the root cause: eliminating malware, closing the exploited vulnerability, revoking all compromised access. This phase requires at least minimal forensic analysis to ensure you removed everything, not just the visible part. Skipping full eradication out of a rush to get back to normal is the most common cause of reinfection.

Recovery is the controlled return to normal operation, with intensified monitoring to detect any sign of remaining persistence. Systems are restored from verified backups or rebuilt from scratch, credentials are fully rotated, and the environment is validated before access is reopened.

Lessons learned closes the cycle with a structured meeting within two weeks of the incident: what happened, what worked, what failed, what changes in the process and controls. This phase turns cost into investment — every well-documented incident reduces the impact of the next one.

What not to do during an incident

Shutting down all systems out of a panic reflex is one of the most costly mistakes. Turning machines off eliminates volatile memory — which often holds the most valuable evidence about what the attacker did and how they got in. Correct isolation keeps the system on but disconnected from the network, preserving the state for analysis.

Deleting logs or reformatting disks before basic forensic analysis is the equivalent of cleaning up a crime scene before the investigators arrive. Even if the intent is to protect sensitive data or speed up recovery, destroying evidence compromises the ability to understand the incident, to meet regulatory obligations, and, in extreme cases, may create legal problems.

Paying a ransom on impulse, without prior analysis, is a decision that should involve at least one consultation with specialists before it is made. Paying does not guarantee data recovery, funds the development of new attacks, and may violate international sanctions depending on the attacking group. In some cases, the decryption provided by the attacker is incomplete or defective even after payment.

Communicating publicly before having the facts is another common mistake at startups that, out of transparency or user pressure, release inaccurate information in the first few hours. Premature communication can tip off the attacker that they have been detected, compromise the investigation, and create legal obligations before the real scope is known.

Legal obligations: LGPD, ANPD, and BACEN

The General Data Protection Law (LGPD) establishes that the controller must report to the National Data Protection Authority (ANPD) any security incident that may pose relevant risk or harm to data subjects. The regulatory deadline consolidated by the ANPD is up to 3 business days counted from the moment the controller becomes aware of the incident.

The report to the ANPD must contain minimum information: the nature of the affected data, the approximate number of data subjects, the technical and security measures taken, the risks related to the incident, and the measures taken or that will be taken. Startups that do not document the incident in real time struggle to meet this requirement, which can result in an additional sanction for failing in the duty to report.

Fintechs and companies operating in the financial system have additional obligations to the Central Bank of Brazil, especially under Resolution BCB No. 85/2021 and complementary rules on cybersecurity for payment and financial institutions. These rules require a formalized incident response plan, periodic testing, and reporting of relevant incidents to the authority. Non-compliance can result in the cancellation of the operating authorization.

Beyond regulatory obligations, contracts with enterprise clients frequently include breach-notification clauses with shorter deadlines than the regulatory ones — sometimes 24 or 48 hours. Reviewing these contracts before an incident is part of minimum viable preparation.

When and how to engage an external IR partner

Engaging an external incident response partner should happen as early as possible after confirming that the incident is real. The tendency to try to solve it internally before asking for help is understandable, but every hour without proper containment widens the scope of the compromise and increases the cost of recovery.

With an active retainer, engagement is simple: a call or message to the emergency channel defined in the contract, with the initial information collected during the detection phase. The IR company already knows the client's basic environment — from the retainer onboarding — and can begin remote triage within minutes.

Without a retainer, the process of hiring in an emergency involves negotiating scope and an NDA under pressure, transferring context from scratch, and often competing for resource allocation with other clients in an emergency. The average cost of IR hired in an emergency in Brazil is significantly higher than that of an annual retainer for small and mid-sized startups.

Decripte offers 24x7 incident response and an IR retainer for startups from 1 to more than 100,000 employees, with an engagement SLA defined in the contract and a team specialized in cloud, fintech, and SaaS environments. The free Threat Management plan already includes leak monitoring and an initial assessment — a way to start at no cost and evolve as the maturity of your operation demands. To sign up for the retainer or the incident response plan, visit decripte.com.br/plano/resposta-incidentes.

Practical checklist

1. 1

   1. Document the basic response plan

   Create a document of at most two pages with the criteria for declaring an incident, the list of escalation contacts (internal and external), the location of the emergency credentials, and the priority order of actions. Keep a copy offline or outside the main work environment.

2. 2

   2. Enable MFA on every critical account

   Review access to cloud, code repositories, payment platforms, DNS, and corporate email. Enable MFA on all of these accounts — preferably with a hardware token or a TOTP app. Revoke any active session after enabling it and audit users with privileged access.

3. 3

   3. Set up immutable backups and test the restore

   Enable immutable retention policies at your cloud providers for the most critical backups. Schedule a full restore test at least once per quarter. Document the actual recovery time and keep that number visible to the engineering team.

4. 4

   4. Centralize logs outside the operational environment

   Configure forwarding of authentication logs, privileged-access logs, and infrastructure-change logs to a separate destination — a bucket with restricted access control or a lightweight SIEM. Set a minimum retention of 90 days to have useful history for an investigation.

5. 5

   5. Sign an IR retainer before you need it

   Evaluate incident response providers, check the engagement SLA and the services covered by the retainer — remote triage, forensics, containment, regulatory communication. Sign the contract and complete the context onboarding while everything is working normally.

6. 6

   6. Run the NIST cycle in the correct order

   When the incident happens: preserve evidence before acting, isolate without shutting down, remove the root cause completely before restoring, return to normal with intensified monitoring, and document the lessons learned within two weeks of closing it out.

7. 7

   7. Meet regulatory deadlines without improvising

   Notify the ANPD within 3 business days of becoming aware of the incident if personal data is affected. Fintechs must check the additional obligations of the Central Bank. Review contracts with enterprise clients to identify contractual notification deadlines, which may be shorter than the regulatory ones.

Frequently asked questions