How to respond to a vulnerability report

Acknowledge the report without overpromising

Confirm receipt, assign an internal reference, and say when the reporter can expect the next update. Keep the first reply factual: it does not confirm validity, severity, scope, or a reward. If nobody can review the report promptly, say so and give a realistic update date.

Subject: We received your security report — [REPORT-ID]

Hello [REPORTER NAME],

Thank you for reporting a possible security issue affecting [PRODUCT / ASSET]. We received your message on [DATE] and recorded it as [REPORT-ID]. We will check whether the report is reproducible and within the published scope. Our aim is to send an initial status update by [DATE OR TIMEFRAME]. If the review takes longer, we will let you know.

Until we agree on next steps, please stop testing the reported issue. Do not access, change, or delete data that does not belong to you. This acknowledgment does not confirm that the issue is valid or eligible for a reward.

Regards,
[SECURITY TEAM / CONTACT]

Replace every bracketed field before sending. Avoid promising a fixed remediation date unless the person responsible for the fix has approved it.

Use a short, repeatable triage sequence

1. Log receipt. Record the date, reporter’s preferred contact, affected asset, and a private report ID.
2. Check authority and scope. Compare the asset and described test with the policy your organization published. A contact address alone does not authorize testing.
3. Ask for minimal, redacted evidence. Request reproduction steps and observed impact. Tell the reporter to remove cookies, tokens, passwords, customer data, and unrelated personal information.
4. Assign an owner and update date. Identify who validates the report, who owns a fix, and when the next status message is due.
5. Close only after verification. Distinguish “fix deployed” from “fix retested.” Explain the outcome privately and coordinate any public disclosure.

Handle sensitive or out-of-scope findings carefully

If a report includes real user data, credentials, or an asset the organization does not control, limit access to people who need it. Do not ask the reporter to collect more data. Coordinate a safe channel and the smallest next step with the appropriate owner.

Keep reports private during review. Do not ask for a public proof of concept, and do not run additional tests unless they are authorized and low-impact. Ask qualified counsel to review any legal safe-harbor wording for your organization and jurisdiction.

What to include in the next update

State the current status, the evidence reviewed, the next owner or action, and the date of another update if the report remains open. If the report is out of scope or cannot be reproduced, explain the decision in plain terms and invite only non-sensitive, authorized evidence that could change the assessment.

Confirma el reporte sin prometer de más

Confirma la recepción, asigna una referencia interna e indica cuándo recibirá la siguiente actualización la persona que reportó. La primera respuesta debe ser objetiva: no confirma validez, gravedad, alcance ni recompensa. Si nadie puede revisar el reporte pronto, dilo y proporciona una fecha realista para actualizar el estado.

Asunto: Recibimos tu reporte de seguridad — [ID-REPORTE]

Hola [NOMBRE DE LA PERSONA REPORTANTE]:

Gracias por informar sobre un posible problema de seguridad que afecta a [PRODUCTO / ACTIVO]. Recibimos tu mensaje el [FECHA] y lo registramos con el código [ID-REPORTE]. Revisaremos si se puede reproducir y si está dentro del alcance publicado. Nuestro objetivo es enviarte una actualización inicial antes de [FECHA O PLAZO]. Si la revisión tarda más, te avisaremos.

Hasta que acordemos los siguientes pasos, detén las pruebas del problema reportado. No accedas, modifiques ni elimines datos ajenos. Este acuse no confirma que el problema sea válido ni que pueda recibir una recompensa.

Saludos,
[EQUIPO DE SEGURIDAD / CONTACTO]

Reemplaza todos los campos entre corchetes antes de enviarlo. No prometas una fecha fija de corrección salvo que la persona responsable ya la haya aprobado.

Usa una secuencia breve y repetible para el triage

1. Registra la recepción. Anota la fecha, el medio de contacto preferido, el activo afectado y una referencia privada.
2. Revisa la autoridad y el alcance. Compara el activo y la prueba descrita con la política publicada por tu organización. Una dirección de contacto, por sí sola, no autoriza pruebas.
3. Pide evidencia mínima y redactada. Solicita los pasos de reproducción y el impacto observado. Indica que deben quitar cookies, tokens, contraseñas, datos de clientes y datos personales ajenos al reporte.
4. Asigna responsable y fecha de actualización. Define quién valida el reporte, quién se encarga de corregirlo y cuándo se enviará el próximo estado.
5. Cierra solo después de verificar. Distingue entre “corrección publicada” y “corrección probada de nuevo”. Comunica el resultado en privado y coordina cualquier divulgación pública.

Protege los hallazgos sensibles o fuera del alcance

Si el reporte incluye datos reales de usuarios, credenciales o un activo que la organización no controla, limita el acceso a las personas que los necesitan. No pidas que recopilen más datos. Coordina un canal seguro y el siguiente paso mínimo con la persona responsable.

Mantén los reportes privados durante la revisión. No pidas una prueba de concepto pública ni ejecutes pruebas adicionales salvo que estén autorizadas y sean de bajo impacto. Pide a un profesional legal que revise cualquier lenguaje de puerto seguro para tu organización y jurisdicción.

Qué incluir en la siguiente actualización

Indica el estado actual, la evidencia revisada, la siguiente acción o responsable y la fecha de otra actualización si el caso sigue abierto. Si el reporte está fuera del alcance o no se puede reproducir, explica la decisión con claridad y pide solo evidencia no sensible y obtenida con autorización que pudiera cambiar la evaluación.