Incident management

Documentation Mercado Libre

Check out all the necessary information about APIs Mercado Libre.

Last update 06/04/2026

Incident management

Security incident management is the set of processes, roles and tools that allow an organization to detect, respond to, and recover from events that compromise the security of its systems or data. It is not just about reacting when something goes wrong, but about having a structured plan that minimizes impact, accelerates recovery and turns each incident into an opportunity for improvement.

Important:

Always notify MercadoLibre at security@mercadolibre.com as soon as possible if the incident involves tokens, seller or buyer data, or affects the integration.

Without an incident plan	With an incident plan
Panic and confusion	Clear steps to follow
Not knowing who to call	Defined contacts and roles
Improvised decisions	Tested processes and measures
Late or incorrect communication	Planned notifications
Repeating the same mistakes	Continuous improvement with post-mortems

The impact of a slow response:

Metric	Without a plan	With a plan
Containment time	Days or weeks	Hours
Average incident cost	+55% higher	Controlled
Reputational damage	Severe (news and media)	Minimized
Regulatory fines	Maximum (for not notifying in time)	Reduced or avoided
Customer losses	A good percentage may leave	Minimal with good communication.

Severity classification of incidents

Not all incidents require the same response; classifying them allows correct prioritization:

SEVERITY	CRITERIA	RESP. TIME	EXAMPLE
● Critical (P1)	Confirmed breach, exposed data, multiple sellers affected.	Immediate ( < 15 min )	Tokens from 100+ sellers exposed on the internet.
● High (P2)	Exploitable vulnerability, potential exposure, degraded service.	< 1 hour	SQL injection detected, exploitation not confirmed.
● Medium (P3)	Vulnerability identified without exploitation, limited impact.	< 4 hours	Certificate about to expire, vulnerable dependency.
● Low (P4)	Security improvement, minor finding.	< 24 hours	Weak password in test account.

The incident response cycle (NIST Framework)

The NIST SP 800-61 standard defines 4 phases for incident management:

Roles and responsibilities during an incident

Define who does what BEFORE the incident occurs:

Role	Responsibility
Incident Commander (IC)	Leads the response, makes decisions, coordinates.
Technical Lead	Investigates root cause, executes technical containment.
Communications Lead	Drafts and sends communications to affected parties.
Scribe / Documentarian	Records timeline, decisions, actions.
Subject Matter Expert	Provides specific knowledge according to the type of incident.

Important:

Define backups for each role (What if the IC is on vacation?).
Publish this information where everyone can find it.
Update when there are personnel changes.

Communication during incidents

Communication can make or break your reputation. Key principles:

Internal communication:

What to communicate	When	To whom
Incident detected	Immediately	Response team
Status updates	Every 30 - 60 min	Leadership and stakeholders
Resolution	On closure	The entire organization

External communication: affected sellers / users:

Be transparent: do not minimize or hide.
Be timely: communicate as soon as possible, even if you don't have all the details.
Be clear: avoid technical jargon.
Be actionable: inform what they should do (change password, revoke permissions, etc.)

Notification template:

Effective Post-mortem process

A resolved incident is not the end, it is the beginning of learning. The post-mortem is the process of analyzing what happened, why it happened, and what we can do to prevent it from happening again. It is the difference between repeating the same mistakes and building an increasingly robust system.

Post-mortem principles:

Assume good intent: everyone acted with the best available information.
Focus on systems, not people: "Why did the system allow this?" vs "Who made the mistake?".
Find root causes: use "5 Whys" to get to the bottom; it consists of asking Why? repeatedly until reaching the fundamental cause of the problem.
Generate concrete actions: each lesson must have an assigned action item.

Post-mortem structure

Incident response metrics

What is not measured cannot be improved. Incident response metrics allow you to know if your team is improving over time, identify bottlenecks in the process, and justify security investments with concrete data.

Metric	What it measures	Goal
MTTD (Mean Time To Detect)	Time from occurrence until detection.	< 1 hour
MTTA (Mean Time To Acknowledge)	Time from detection until someone responds.	< 15 minutes
MTTC (Mean Time To Contain)	Time until damage is contained.	< 4 hours
MTTR (Mean Time To Resolve)	Time until fully resolved.	Depends on severity
Incidents per month	Number of incidents.	Downward trend
Post-mortems completed	% of P1/P2 incidents with post-mortem.	100%

Incident response example

Let's see what a chaotic vs organized response looks like:

References

NIST SP 800-61: computer security incident handling guide.
OWASP Incident Response: incident response scenarios.
SANS Incident Handler's Handbook: practical incident management manual.

Glossary

Term	Meaning
Security incident	Event that compromises or may compromise the confidentiality, integrity or availability of data.
Breach	Confirmed incident where sensitive data was accessed or exfiltrated.
Containment	Immediate actions to limit the damage of an ongoing incident.
Eradication	Eliminating the root cause of the incident (e.g.: closing the vulnerability).
Recovery	Restoring systems and services to normal operation.
Post-mortem	Post-incident analysis to learn and prevent recurrence.
Playbook	Step-by-step guide on how to respond to specific types of incidents.
Response time	Time from when an incident is detected until actions are taken.
Notification	Communicating the incident to affected parties (users, regulators, MercadoLibre).