Creación de políticas y procedimientos de seguridad

Este capítulo cubre la creación de tres políticas esenciales: Política de Uso Aceptable (lo que los empleados pueden y no pueden hacer), Plan de Respuesta a Incidentes (qué hacer cuando algo sale mal) y Política de Clasificación de Datos (cómo manejar diferentes tipos de datos). Obtendrá plantillas que puede adaptar en una tarde, no marcos que requieren un comité.

Por qué importan las políticas en las pequeñas empresas

"Somos solo 20 personas, todos saben qué hacer" — esto funciona hasta que deja de funcionar. Las políticas importan porque:

Las personas se van y llegan. ¿Ese conocimiento tribal en la cabeza de todos? Se va cuando alguien renuncia. Los nuevos empleados no saben qué es aceptable a menos que lo escriba.

Los incidentes suceden rápido. Cuando está lidiando con una brecha a las 2 AM, no tiene tiempo para averiguar a quién llamar, qué preservar o qué decirles a los clientes. Necesita un plan que pueda seguir en piloto automático.

Protección de responsabilidad. Si un empleado hace algo estúpido y usted no tiene ninguna política que lo prohíba, buena suerte en los tribunales. Las políticas escritas establecen expectativas y brindan cobertura legal.

Requisitos de clientes y socios. Incluso las pequeñas empresas B2B reciben la pregunta "¿tienen políticas de seguridad?" de los clientes potenciales. Tener políticas reales (no solo "nos importa la seguridad") cierra negocios.

Requisitos del seguro. El seguro cibernético requiere cada vez más políticas documentadas. Sin políticas = primas más altas o reclamaciones denegadas.

El objetivo no es burocracia. Es tener respuestas claras a preguntas comunes para no tener que reinventar la rueda cada vez que surge algo.

Principios para escribir políticas

Antes de sumergirse en políticas específicas, entienda qué hace efectiva a una política:

Manténgala breve

Si su política tiene más de 3 páginas, las personas no la leerán. Una política que nadie lee es peor que ninguna política — crea una falsa confianza.

Extensiones objetivo:

• Política de Uso Aceptable: 2-3 páginas
• Plan de Respuesta a Incidentes: 3-5 páginas
• Clasificación de Datos: 1-2 páginas

Use lenguaje sencillo

Escriba para sus empleados reales, no para abogados o auditores. Si necesita un abogado para interpretar su política, vuelva a escribirla.

MAL: "Los empleados deberán abstenerse de utilizar los recursos informáticos 
     corporativos para propósitos no directamente relacionados con actividades 
     de negocio autorizadas."

BIEN: "No use computadoras de trabajo para cosas personales que podrían meternos 
      en problemas: software pirata, contenido inapropiado o administrar un negocio paralelo."

Sea específico sobre las consecuencias

Las amenazas vagas no funcionan. "Las violaciones pueden resultar en acción disciplinaria" no significa nada. Sea concreto:

MAL: "Las violaciones de esta política pueden resultar en acción disciplinaria."

BIEN: "Primera violación: Advertencia verbal y capacitación de seguridad requerida.
      Segunda violación: Advertencia escrita en el expediente del personal.
      Violaciones graves (brecha de datos, infección de malware): Terminación inmediata posible."

Incluya el "por qué"

Las personas siguen las reglas que entienden. Explique el razonamiento:

MAL: "Los dispositivos personales no deben conectarse a la red corporativa."

BIEN: "Los dispositivos personales no pueden conectarse a nuestra red porque no podemos 
      verificar que sean seguros. Los dispositivos personales infectados han causado 
      grandes brechas en otras empresas. Use WiFi para invitados para teléfonos personales."

Deje las excepciones claras

Cada regla tiene excepciones. Documéntelas o las personas inventarán las suyas:

**Política:** El software debe ser aprobado antes de la instalación.

**Excepción:** Los miembros del equipo de desarrollo pueden instalar paquetes 
a través de npm/pip/brew para sus proyectos sin aprobación. Sin embargo, los 
paquetes en los despliegues de producción deben ser analizados en busca de vulnerabilidades.

Aprenda de las empresas que publican sus políticas

No tiene que empezar desde cero. Varias empresas tecnológicas publican sus políticas de seguridad y manuales de manera abierta. Estúdielos para la estructura, el lenguaje y el alcance — luego adáptelos a su contexto.

Ejemplos de políticas públicas

Empresa	Qué publican	Por qué es útil	Enlace
GitLab	Manual de seguridad completo: clasificación de datos, respuesta a incidentes, uso aceptable, procedimientos de guardia	Extremadamente detallado, cubre casos extremos, bueno para empresas tecnológicas	handbook.gitlab.com/handbook/security
PagerDuty	Documentación de respuesta a incidentes (código abierto)	El estándar de oro para el proceso de IR, usado por miles de empresas	response.pagerduty.com
Atlassian	Manual de gestión de incidentes y playbooks	Excelentes definiciones de severidad y plantillas de comunicación	atlassian.com/incident-management
Mattermost	Políticas de seguridad en el manual público	Buen ejemplo para empresas tecnológicas más pequeñas	handbook.mattermost.com
Basecamp	Manual del empleado en GitHub	Políticas prácticas en lenguaje sencillo	github.com/basecamp/handbook

Plantillas de políticas gratuitas

Recurso	Qué obtiene	Ideal para	Enlace
SANS Policy Templates	60+ plantillas listas para usar (PUA, PRI, Política de contraseñas, Acceso remoto, etc.)	Inicio rápido con lenguaje estándar del sector	sans.org/information-security-policy
NIST Small Business Cybersecurity	Guías, listas de verificación y marcos diseñados para PYME	Respaldo del liderazgo no técnico	nist.gov/itl/smallbusinesscyber
CIS Controls	Controles de seguridad priorizados con grupos de implementación por tamaño de empresa	Enfoque estructurado, IG1 es perfecto para pequeñas empresas	cisecurity.org/controls
CISA Incident Response Playbooks	Playbooks federales para ransomware, respuesta a vulnerabilidades	Cuando necesita guías detalladas de IR paso a paso	cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf

Inicio rápido: políticas mínimas viables

Si necesita políticas HOY y tiene tiempo limitado:

1. Política de Uso Aceptable (30 minutos)

• Descargue la plantilla de Política de Uso Aceptable de SANS
• Reemplace el nombre de la empresa y la información de contacto
• Elimine las secciones que no aplican
• Añada sus herramientas y servicios específicos
• Listo — itere después

2. Plan de Respuesta a Incidentes (1 hora)

• Estudie la estructura de response.pagerduty.com de PagerDuty
• Copie sus definiciones de severidad
• Añada la información de contacto de su equipo
• Cree una convención básica de nombres de canales de Slack
• Puede añadir playbooks después

3. Clasificación de Datos (20 minutos)

• Use el esquema de 4 niveles: Público / Interno / Confidencial / Restringido
• Liste 3-5 ejemplos de cada nivel de sus datos reales
• Defina dónde se puede almacenar cada nivel
• Eso es todo — amplíe según sea necesario

Comience simple, itere

Una política de 2 páginas que realmente usa supera a una política de 20 páginas que nadie lee. Publique v1.0 rápido, luego mejore basándose en preguntas e incidentes reales.

Incidentes reales: qué sucede sin políticas

No son tácticas de miedo — son lecciones de empresas que lo aprendieron de la manera difícil.

Sin Plan de Respuesta a Incidentes

Uber (2016): Cuando los atacantes accedieron a los datos de 57 millones de usuarios, Uber no tenía un proceso de IR documentado. En lugar de una respuesta adecuada, pagaron a los atacantes $100,000 para que eliminaran los datos y guardaran silencio. Resultado: acuerdo de $148 millones, cargos criminales contra el CISO, daño masivo a la reputación. Un PRI documentado habría guiado una notificación de brecha adecuada.

Equifax (2017): La brecha que afectó a 147 millones de personas se agravó por una respuesta caótica. Sin roles claros, proceso de parcheo retrasado, sin plan de comunicación. El CEO testificó ante el Congreso que no sabían quién era responsable del parcheo. El costo total superó los $1.4 mil millones.

Sin Política de Uso Aceptable

Twitter (2020): Los atacantes usaron ingeniería social por teléfono en empleados para obtener acceso a herramientas internas, luego secuestraron cuentas de alto perfil (Obama, Elon Musk, Apple). Una PUA clara sobre el manejo de credenciales y el reporte de ingeniería social podría haber ayudado a los empleados a reconocer y reportar el ataque antes.

SolarWinds (2020): Se informó que un pasante usó la contraseña "solarwinds123" en un servidor crítico. Sin políticas de contraseñas aplicadas y directrices claras de uso aceptable, falló la higiene básica de seguridad.

Sin Clasificación de Datos

Capital One (2019): Un WAF mal configurado expuso 100 millones de registros de clientes. Parte del problema: sin clasificación de datos clara, los datos sensibles se almacenaban junto con datos menos críticos, aumentando la exposición. Costo: multa de $80 millones, acuerdo de $190 millones.

El patrón: las empresas sin políticas documentadas toman peores decisiones bajo presión, tardan más en responder y enfrentan consecuencias regulatorias más severas.

Política de Uso Aceptable (PUA)

La PUA define lo que los empleados pueden y no pueden hacer con los recursos de la empresa: computadoras, red, correo electrónico, servicios en la nube y datos. Es la base de todas las políticas de seguridad.

Qué cubrir

1. Propósito y alcance — a quién aplica, qué recursos cubre
2. Principios generales — expectativas básicas: profesionalismo, sin actividad ilegal
3. Requisitos de cuentas y contraseñas — reglas de contraseñas, MFA, sin compartir credenciales
4. Correo electrónico y comunicación — uso profesional, conciencia de phishing, límites del correo personal
5. Internet y redes sociales — qué está permitido durante el trabajo, representar a la empresa en línea
6. Software y descargas — qué se puede instalar, proceso de aprobación
7. Dispositivos personales (BYOD) — ¿pueden los dispositivos personales acceder a datos de la empresa? ¿bajo qué reglas?
8. Manejo de datos — cómo tratar los datos de la empresa y de los clientes
9. Trabajo remoto — requisitos de VPN, WiFi público, seguridad física en casa
10. Monitoreo y privacidad — qué monitorea la empresa, expectativas de privacidad del empleado
11. Reporte de violaciones — cómo reportar inquietudes, protección contra represalias
12. Consecuencias — qué sucede cuando se viola la política

Plantilla de PUA

Aquí hay una plantilla lista para usar. Personalice las secciones entre corchetes para su empresa:

# [COMPANY NAME] Acceptable Use Policy

**Effective date:** [DATE]
**Last updated:** [DATE]
**Owner:** [SECURITY CHAMPION NAME]

## Purpose

This policy defines acceptable use of [COMPANY NAME] technology resources. 
Following these guidelines protects you, your colleagues, and our customers.

## Scope

This policy applies to:
- All employees, contractors, and temporary workers
- All company-owned devices and accounts
- Personal devices when accessing company data
- All use of company network and cloud services

## Your responsibilities

### Accounts and passwords

- Use unique passwords of at least [12/14/16] characters for all work accounts
- Enable MFA on all accounts that support it (mandatory for [list critical services])
- Never share your credentials with anyone — including IT or your manager
- Lock your computer when stepping away (Windows+L or Cmd+Ctrl+Q)
- Report suspected account compromise immediately to [CONTACT]

### Email and communication

- Use company email for work communication only
- Don't open unexpected attachments — verify with sender first
- Report suspicious emails to [SECURITY EMAIL/CHANNEL]
- Don't use company email to sign up for personal services
- Assume all email could become public in a legal dispute

### Internet use

Personal internet use during breaks is acceptable within reason. Don't:
- Access illegal content
- Download pirated software or media
- Use excessive bandwidth (streaming during work hours)
- Access content that would embarrass the company if discovered

### Software installation

- Approved software: [LIST OR LINK TO APPROVED SOFTWARE LIST]
- To request new software: [PROCESS]
- Never install software from untrusted sources
- Browser extensions must be from official stores only
- Developers: Package managers (npm, pip, brew) are allowed for development

### Personal devices (BYOD)

If you access company data on personal devices:
- Device must have screen lock enabled
- Install security updates within 1 week of release
- Company reserves right to remote wipe company data if device is lost
- Don't store customer data on personal devices
- Use [APPROVED MDM] if accessing email on mobile

### Remote work

- Use company VPN when accessing internal resources
- Don't work on sensitive data in public places (coffee shops, airports)
- Secure your home WiFi with WPA3 or WPA2 and a strong password
- Don't let family members use work devices

### Data handling

- Treat all customer data as confidential
- Don't share company data through personal email or messaging apps
- Use approved file sharing services: [LIST]
- Don't copy company data to personal cloud storage
- See Data Classification Policy for details

## Company monitoring

[COMPANY NAME] monitors company resources to protect security. This includes:
- Email (content and metadata)
- Web browsing history
- File access logs
- Login times and locations

We don't monitor personal devices except for company apps installed on them.

## Reporting concerns

Report policy violations or security concerns to [CONTACT]. Reports can be 
anonymous via [MECHANISM]. We don't retaliate against good-faith reports.

## Consequences

| Violation type | First offense | Repeat offense |
|---------------|---------------|----------------|
| Minor (e.g., unapproved software) | Warning + training | Written warning |
| Moderate (e.g., sharing credentials) | Written warning | Suspension possible |
| Severe (e.g., data breach, malware) | Termination possible | Termination |

Severity is determined by [ROLE, e.g., HR in consultation with Security Champion].

## Questions

Contact [SECURITY CHAMPION NAME] at [EMAIL] with any questions about this policy.

---

**Acknowledgment**

I have read and understand the [COMPANY NAME] Acceptable Use Policy.

Name: ____________________
Signature: ________________
Date: ____________________

Errores comunes de la PUA

Error	Por qué es un problema	Solución
Copiar políticas empresariales	Demasiado compleja, irrelevante para su contexto	Escriba desde cero, manténgala breve
Sin aplicación	La política se convierte en sugerencia	Defina consecuencias claras, cúmplalas
Tecnología desactualizada	Hace referencia a faxes, ignora la nube	Actualice anualmente, refleje las herramientas reales
Demasiado restrictiva	Las personas evaden las reglas	Equilibre seguridad con productividad
Sin proceso de excepciones	Las personas ignoran la política cuando bloquea el trabajo	Documente cómo solicitar excepciones
Jerga legal	Nadie la lee	Escriba en lenguaje sencillo

Plan de Respuesta a Incidentes (PRI)

Cuando algo sale mal — ransomware, brecha de datos, cuenta comprometida — necesita un plan. El PRI le dice a todos exactamente qué hacer. No es estrategia; es una lista de verificación para una crisis.

Por qué necesita un PRI antes de un incidente

Durante un incidente, estará estresado, sin dormir y tomando decisiones rápidas. Ese es el peor momento para averiguar:

• ¿Quién debería hacer qué?
• ¿A quién llamamos externamente?
• ¿Cuál es la comunicación con los clientes?
• ¿Estamos preservando evidencia correctamente?

Escriba el PRI cuando esté tranquilo. Sígalo cuando entre en pánico.

Estructura del PRI

1. Clasificación de incidentes — qué cuenta como incidente, niveles de severidad
2. Equipo de respuesta y roles — quién hace qué durante un incidente
3. Detección y reporte — cómo nos enteramos de los incidentes
4. Contención — detener el sangrado, aislar los sistemas afectados
5. Investigación — entender qué sucedió
6. Erradicación y recuperación — eliminar la amenaza, restaurar las operaciones normales
7. Comunicación — interna, cliente, regulatoria, pública
8. Revisión post-incidente — aprender y mejorar
9. Lista de contactos — todos a quienes podría necesitar llamar

Plantilla del PRI

# [COMPANY NAME] Incident Response Plan

**Version:** 1.0
**Effective date:** [DATE]
**Owner:** [SECURITY CHAMPION NAME]
**Review frequency:** Annually or after any major incident

---

## 1. What is an incident?

A security incident is any event that:
- Compromises confidentiality, integrity, or availability of company data
- Violates security policies
- Could harm customers, employees, or the company

### Severity levels

| Level | Description | Examples | Response time |
|-------|-------------|----------|---------------|
| **Critical** | Active attack, major data breach | Ransomware, customer DB exposed | Immediate (within 15 min) |
| **High** | Confirmed compromise, limited scope | Single account compromised, malware on one system | Within 1 hour |
| **Medium** | Potential compromise, needs investigation | Suspicious login, phishing clicked | Within 4 hours |
| **Low** | Policy violation, no confirmed impact | Unauthorized software, failed attack | Within 24 hours |

---

## 2. Response team

### Primary responders

| Role | Person | Phone | Backup |
|------|--------|-------|--------|
| **Incident Lead** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Technical Lead** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Communications** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Executive Sponsor** | [NAME] | [PHONE] | [BACKUP NAME] |

### Role responsibilities

**Incident Lead (usually Security Champion):**
- Coordinates response activities
- Makes containment decisions
- Maintains incident timeline
- Ensures documentation
- Leads post-incident review

**Technical Lead (usually senior developer or DevOps):**
- Performs technical investigation
- Implements containment measures
- Leads eradication and recovery
- Preserves evidence

**Communications (usually CEO or Head of Customer Success):**
- Drafts customer communications
- Handles media inquiries
- Coordinates with legal
- Internal employee updates

**Executive Sponsor (CEO or CTO):**
- Authorizes major decisions (system shutdown, customer notification)
- External stakeholder communication
- Resource allocation

---

## 3. Detection and reporting

### How we detect incidents

- Employee reports suspicious activity
- Automated alerts (monitoring, SIEM, security tools)
- Customer complaints
- Third-party notification (vendor, researcher)
- Law enforcement contact

### Reporting an incident

**Any employee who suspects an incident must:**

1. Don't try to fix it yourself
2. Report immediately via:
   - Slack: #security-incidents (preferred for speed)
   - Email: security@[company].com
   - Phone: [SECURITY CHAMPION PHONE] (after hours)
3. Include:
   - What you observed
   - When it happened
   - Systems/accounts involved
   - Any actions you've already taken

---

## 4. Initial response (first 30 minutes)

### Incident Lead actions

1. ☐ Acknowledge report, assign severity level
2. ☐ Create incident channel: #incident-[DATE]-[BRIEF-NAME]
3. ☐ Alert response team members based on severity
4. ☐ Start incident log (use template below)
5. ☐ Assess: Is containment needed immediately?

### Incident log template

Incident Log: [INCIDENT NAME]

Reported: [DATE TIME] Reported by: [NAME] Severity: [LEVEL] Status: [INVESTIGATING / CONTAINED / RESOLVED]

Timeline

Time	Action	Person	Notes
14:32	Incident reported	Jane	Suspicious login from Russia
14:35	Response team alerted	Security Champion	Via Slack
14:42	Account suspended	DevOps	Revoked all sessions
...	...	...	...

Affected systems

• [LIST]

Evidence preserved

• [LIST]

Key decisions

• [DATE TIME] Decided to [DECISION] because [REASON]. Decided by [WHO].

---

## 5. Containment

**Goal:** Stop the incident from getting worse. Speed matters more than perfection.

### Containment options (choose based on situation)

| Action | When to use | How |
|--------|-------------|-----|
| **Disable account** | Compromised credentials | Admin console → Suspend user |
| **Revoke sessions** | Active unauthorized access | Force logout all sessions |
| **Isolate system** | Malware, active attacker | Disconnect from network |
| **Block IP/domain** | Known attacker infrastructure | Firewall/DNS block |
| **Disable service** | Vulnerable application | Take offline temporarily |
| **Rotate credentials** | Exposed secrets | Generate new, update everywhere |
| **Revoke API keys** | Key compromised | Regenerate in service console |

### Evidence preservation

Before destroying evidence (wiping systems, deleting accounts):

1. Take screenshots of relevant logs and screens
2. Export audit logs from affected services
3. Copy access logs from web servers
4. Note IP addresses, timestamps, user agents
5. For malware: image the disk before wiping

**Store evidence in:** [SECURE LOCATION, e.g., locked folder, separate account]

---

## 6. Investigation

### Questions to answer

- What happened? (Attack vector, timeline)
- How did they get in? (Credentials, vulnerability, social engineering)
- What did they access? (Data, systems)
- What did they take or change?
- Are they still in? (Persistence mechanisms)
- Who else might be affected?

### Investigation sources

| Source | What to check | How to access |
|--------|--------------|---------------|
| **Cloud audit logs** | Login attempts, API calls | AWS CloudTrail, GCP Audit Logs, Azure Activity |
| **Email logs** | Phishing, data exfiltration | Google Admin, Microsoft 365 Security |
| **Application logs** | Unauthorized actions | Your logging system |
| **Endpoint logs** | Malware, lateral movement | EDR if you have it, Windows Event Log |
| **Network logs** | Connections, data transfer | Firewall, VPN logs |
| **Git history** | Code tampering | git log, GitHub audit log |

### When to call for help

Call external help (incident response firm) if:
- You're in over your head technically
- Significant customer data is exposed
- Law enforcement may need to be involved
- Insurance requires professional investigation
- Attack is ongoing and you can't contain it

**Incident response contacts:**
- [IR FIRM NAME]: [PHONE] — [NOTES ON ENGAGEMENT]
- Cyber insurance hotline: [PHONE] — Policy #[NUMBER]

---

## 7. Eradication and recovery

### Eradication checklist

- ☐ Remove attacker access (all credentials rotated, backdoors removed)
- ☐ Patch vulnerability that allowed entry
- ☐ Remove malware from all affected systems
- ☐ Verify no persistence mechanisms remain
- ☐ Scan other systems for indicators of compromise

### Recovery steps

1. ☐ Restore systems from known-good backups if needed
2. ☐ Verify integrity of restored data
3. ☐ Re-enable disabled services gradually
4. ☐ Monitor closely for re-infection
5. ☐ Confirm normal operations

### Recovery validation

Before declaring "all clear":
- Run security scans on affected systems
- Review logs for 24-48 hours post-recovery
- Verify no unauthorized changes to critical files
- Test affected functionality

---

## 8. Communication

### Internal communication

| Audience | When | Who communicates | Channel |
|----------|------|-----------------|---------|
| Response team | Immediately | Incident Lead | Incident Slack channel |
| Leadership | Critical/High: immediately; others: daily | Incident Lead | Email/call |
| All employees | When contained or if they need to act | Communications Lead | All-hands email/Slack |

### Customer communication

**Decision matrix:**

| Situation | Notification required? | Timeline |
|-----------|----------------------|----------|
| Customer data accessed | Yes | Within [72 hours for GDPR, varies by law] |
| Service outage only | Consider, especially if prolonged | As appropriate |
| Internal incident, no customer impact | No | N/A |

**Customer notification template:**

Subject: Security Notification from [COMPANY]

Dear [CUSTOMER],

We're writing to inform you about a security incident that may affect your data.

What happened: [Brief, factual description]

What data was involved: [Specific data types, be precise]

What we're doing: [Actions taken and ongoing]

What you can do: [Specific recommendations: change passwords, monitor accounts, etc.]

How to contact us: [Dedicated email/phone for incident inquiries]

We take the security of your data seriously and apologize for any concern this causes. We'll provide updates as we learn more.

[SIGNATURE]

### Regulatory notification

**Check requirements for:**
- GDPR (72 hours to supervisory authority)
- State breach notification laws (varies by US state)
- Industry regulations (HIPAA, PCI DSS)
- Contractual obligations to customers

**Keep legal counsel informed** for anything involving customer data.

---

## 9. Post-incident review

### Blameless postmortem

Within 1 week of resolution, conduct a review:

**Attendees:** All responders, relevant stakeholders

**Agenda:**
1. Timeline review — what happened, when?
2. What went well?
3. What could have gone better?
4. Action items to prevent recurrence
5. Action items to improve response

### Postmortem template

```markdown
## Incident Postmortem: [INCIDENT NAME]

**Date of incident:** [DATE]
**Date of review:** [DATE]
**Severity:** [LEVEL]
**Duration:** [TIME FROM DETECTION TO RESOLUTION]

### Summary
[2-3 sentence description]

### Timeline
[From incident log]

### Root cause
[What allowed this to happen?]

### Impact
- Systems affected: [LIST]
- Data affected: [TYPE AND VOLUME]
- Customer impact: [DESCRIPTION]
- Business impact: [COST, DOWNTIME, REPUTATION]

### What went well
- [EXAMPLE]
- [EXAMPLE]

### What could improve
- [EXAMPLE]
- [EXAMPLE]

### Action items
| Action | Owner | Due date | Status |
|--------|-------|----------|--------|
| [ACTION] | [NAME] | [DATE] | ☐ |
| [ACTION] | [NAME] | [DATE] | ☐ |

### Lessons learned
[Key takeaways for the team]

---

10. Contact list

Internal

Role	Name	Phone	Email
Security Champion	[NAME]	[PHONE]	[EMAIL]
CTO	[NAME]	[PHONE]	[EMAIL]
CEO	[NAME]	[PHONE]	[EMAIL]
Legal Counsel	[NAME]	[PHONE]	[EMAIL]
HR	[NAME]	[PHONE]	[EMAIL]

External

Service	Contact	Phone/URL	Account info
Cyber Insurance	[CARRIER]	[PHONE]	Policy #[NUMBER]
IR Firm	[FIRM]	[PHONE]	[RETAINER DETAILS]
Legal (external)	[FIRM]	[PHONE]
FBI	Local field office	[PHONE]	For major crimes
AWS Support		[SUPPORT URL]	[ACCOUNT ID]
Google Workspace		[SUPPORT URL]
[OTHER CRITICAL VENDORS]

---

Appendix: Quick reference cards

If you suspect your account is compromised

1. Change your password immediately
2. Enable MFA if not already enabled
3. Report to #security-incidents
4. Check recent account activity for unauthorized access
5. Don't delete anything — we may need it for investigation

If you clicked a phishing link

1. Disconnect from network (turn off WiFi/unplug ethernet)
2. Report to #security-incidents immediately
3. Don't log into anything else
4. Wait for instructions from response team

If you see ransomware

1. DON'T turn off the computer (may destroy evidence)
2. Disconnect from network immediately
3. Take photo of ransom message
4. Report to #security-incidents
5. Alert people nearby to disconnect too

## Playbooks de incidentes para escenarios comunes

El PRI le da el proceso general. Los playbooks le dan los pasos específicos para tipos de incidentes específicos. Comience con estos cuatro — cubren el 80% de los incidentes que enfrentan las pequeñas empresas.

### Playbook: Cuenta de empleado comprometida

**Severidad:** Generalmente Alta (podría ser Crítica si es una cuenta de administrador)

**Indicadores:**
- Viajes imposibles (inicio de sesión desde dos países en pocas horas)
- Inicio de sesión desde ubicación o dispositivo inusual
- Actividad inusual en los registros de auditoría
- El empleado reporta no reconocer sus propias acciones
- Restablecimiento de contraseña que no solicitó

**Acciones inmediatas (primeros 15 minutos):**

| Paso | Acción | Quién |
|------|--------|-----|
| 1 | Suspender la cuenta (no eliminarla) | TI/Security Champion |
| 2 | Revocar todas las sesiones activas | TI |
| 3 | Deshabilitar tokens/claves de API de ese usuario | DevOps |
| 4 | Contactar al empleado (teléfono, no correo de empresa) | Líder del incidente |
| 5 | Verificar si el MFA estaba habilitado | Security Champion |

**Lista de verificación de investigación:**
- [ ] ¿Cuándo ocurrió el compromiso? (Primer inicio de sesión sospechoso)
- [ ] ¿Cómo entraron? (¿Phishing? ¿Relleno de credenciales? ¿Malware?)
- [ ] ¿A qué accedieron? (Correo, archivos, código, paneles de administración)
- [ ] ¿Qué hicieron? (Leer, descargar, modificar, eliminar)
- [ ] ¿Accedieron a otras cuentas desde esta?
- [ ] ¿Hay otras cuentas comprometidas? (Reutilización de contraseñas)

**Recuperación:**
1. Restablecer contraseña con contraseña aleatoria fuerte
2. Verificar que el MFA esté habilitado (llave de hardware si está disponible)
3. Revisar y revocar permisos innecesarios
4. Borrar todas las sesiones del navegador
5. Analizar el dispositivo del empleado en busca de malware
6. Monitorear la cuenta de cerca durante 30 días

**Comunicación:**
- Empleado: Explicar qué sucedió, sin culpa, ofrecer capacitación de seguridad
- Equipo: Recordatorio general sobre phishing si es relevante
- Clientes: Solo si se accedió a sus datos

---

### Playbook: Ataque de ransomware

**Severidad:** Crítica

**Indicadores:**
- Archivos cifrados con extensiones inusuales
- Nota de rescate en el escritorio o en carpetas
- Sistemas inusualmente lentos o que no responden
- Alertas del antivirus sobre cifrado
- Múltiples empleados reportando problemas simultáneamente

**Acciones inmediatas (primeros 5 minutos):**

| Paso | Acción | Quién | Notas |
|------|--------|-----|-------|
| 1 | NO apague las computadoras afectadas | Todos | Preserva evidencia en memoria |
| 2 | Desconectar de la red | Todos los afectados | Desenchufe el cable, deshabilite WiFi |
| 3 | Alertar a todos los empleados para que se desconecten | Líder del incidente | Slack/SMS/árbol de llamadas |
| 4 | Llamar a la línea directa del seguro cibernético | Patrocinador ejecutivo | Ellos proporcionarán la empresa de IR |
| 5 | Documentar todo (fotos, capturas de pantalla) | Líder técnico | La cronología es crucial |

**NO haga:**
- Pagar el rescate (sin consulta legal/de seguros)
- Comunicarse con los atacantes desde el correo de la empresa
- Eliminar ningún archivo o registro
- Restaurar desde copia de seguridad hasta saber el vector de infección
- Conectar unidades de copia de seguridad a la red infectada

**Prioridades de investigación:**
1. Identificar el paciente cero (primer sistema infectado)
2. Determinar el vector de infección (phishing, RDP, vulnerabilidad)
3. Evaluar el daño (qué está cifrado, qué se exfiltró)
4. Verificar que las copias de seguridad estén íntegras y limpias
5. Identificar qué datos podrían haber sido robados (doble extorsión)

**Recuperación (solo después de la investigación):**
1. Reconstruir sistemas desde imágenes/copias de seguridad conocidas como buenas
2. Parchear la vulnerabilidad que permitió la entrada
3. Restablecer TODAS las credenciales (asumir que todo está comprometido)
4. Restaurar datos desde copias de seguridad limpias
5. Monitorear intensamente para detectar reinfección

**Contactos externos:**
- FBI: ic3.gov para reportar
- CISA: cisa.gov/ransomware
- Su línea directa de IR del seguro cibernético

---

### Playbook: Brecha de datos de clientes

**Severidad:** Crítica (implicaciones regulatorias y legales)

**Indicadores:**
- Acceso no autorizado a la base de datos en los registros
- Datos de clientes encontrados externamente (investigador, dark web, sitio de paste)
- Actividad inusual de exportaciones de datos o de API
- Notificación de terceros

**Acciones inmediatas:**

| Paso | Acción | Quién | Cronograma |
|------|--------|-----|----------|
| 1 | Confirmar que la brecha es real | Líder técnico | Primera hora |
| 2 | Detener el acceso continuo | TI | De inmediato |
| 3 | Alertar al asesor legal | Patrocinador ejecutivo | En 2 horas |
| 4 | Preservar toda la evidencia | Líder técnico | Continuo |
| 5 | Iniciar el reloj regulatorio (GDPR: 72 horas) | Legal | Documentar hora de descubrimiento |

**Preguntas de alcance:**
- ¿Qué tipos de datos se expusieron? (PII, financiero, salud)
- ¿Cuántos registros/individuos afectados?
- ¿Qué jurisdicciones? (Residentes de la UE = GDPR)
- ¿Cuánto tiempo estuvo accesible el dato?
- ¿Se exfiltró el dato o solo se accedió?
- ¿Está cerrada la vulnerabilidad?

**Requisitos de notificación:**

| Regulación | Cronograma | A quién notificar |
|------------|----------|---------------|
| **GDPR** | 72 horas | Autoridad supervisora, luego individuos |
| **CCPA** | "Expedito" | Residentes de California |
| **HIPAA** | 60 días | HHS, individuos, medios si >500 personas |
| **PCI DSS** | De inmediato | Marcas de tarjetas, banco adquirente |
| **Leyes estatales** | Varía | Revise cada estado donde residen los clientes |

**Elementos de la notificación al cliente:**
1. Qué sucedió (factual, breve)
2. Qué datos estuvieron involucrados (específico)
3. Qué está haciendo al respecto
4. Qué deben hacer ellos (cambiar contraseñas, monitorear crédito)
5. Cómo contactarle con preguntas
6. Disculpa

**Protección legal:**
- Documente todo con marcas de tiempo
- No especule en comunicaciones escritas
- Obtenga revisión legal antes de declaraciones externas
- Preserve evidencia para posibles litigios

---

### Playbook: Secretos filtrados en Git

**Severidad:** Alta (podría ser Crítica si son credenciales de producción)

**Indicadores:**
- Alerta de GitHub Secret Scanning
- Alerta de git-secrets, truffleHog o similar
- Notificación del proveedor cloud (AWS, GCP detectan automáticamente algunas claves)
- Reporte de un investigador de seguridad

**Acciones inmediatas (en 15 minutos):**

| Paso | Acción | Quién |
|------|--------|-----|
| 1 | Determinar qué fue expuesto | Security Champion |
| 2 | Rotar la credencial DE INMEDIATO | DevOps/Desarrollador |
| 3 | Verificar si la credencial se usó maliciosamente | DevOps |
| 4 | Eliminar del historial de Git si es posible | Desarrollador |
| 5 | Verificar si el repositorio es público | Security Champion |

**Rotación de credenciales por tipo:**

| Tipo de secreto | Dónde rotar | Pasos adicionales |
|-------------|-----------------|------------------|
| **Claves AWS** | Consola IAM | Verificar CloudTrail para uso no autorizado |
| **Cuenta de servicio GCP** | Consola GCP | Verificar registros de auditoría |
| **Contraseña de base de datos** | Admin de base de datos | Verificar registros de acceso |
| **Clave API (terceros)** | Consola del proveedor | Verificar registros de uso |
| **Secreto JWT** | Configuración de la aplicación | Todos los tokens existentes quedan inválidos |
| **Clave SSH** | Eliminar de authorized_keys | Generar nuevo par de claves |

**Limpieza del historial de Git:**

```bash
# If the commit is only local
git reset --soft HEAD~1
# Remove the secret, recommit

# If already pushed (and repo is private)
# Use BFG Repo-Cleaner
bfg --delete-files 'filename-with-secret'
git push --force

# If repo is public
# Assume the secret is compromised forever
# Focus on rotation, not history cleanup

Prevención:

• Instale hooks de pre-commit (git-secrets, detect-secrets)
• Habilite GitHub Secret Scanning
• Use variables de entorno o gestores de secretos
• Nunca haga commit de archivos .env

Investigación:

• ¿Cuándo se hizo commit del secreto?
• ¿Cuándo se hizo público el repositorio (si aplica)?
• ¿Quién tenía acceso durante esa ventana?
• ¿Alguna actividad inusual usando esa credencial?

Política de Clasificación de Datos

La clasificación de datos le dice a los empleados cómo manejar diferentes tipos de información. Sin ella, las personas o tratan todo como top secret (ineficiente) o nada como sensible (peligroso).

¿Por qué clasificar los datos?

• Enfocar los esfuerzos de protección — No todos los datos necesitan la misma seguridad
• Reglas de manejo claras — Las personas saben qué pueden y no pueden hacer
• Soporte de cumplimiento — Las regulaciones a menudo requieren clasificación
• Respuesta a incidentes — Saber de inmediato qué tan grave es una brecha

Esquema de clasificación simple

Para pequeñas empresas, tres o cuatro niveles es suficiente:

Nivel	Descripción	Ejemplos
Público	Se puede compartir con cualquiera	Materiales de marketing, publicaciones de blog públicas, código open source
Interno	Solo para empleados	Wiki interna, organigrama, políticas generales
Confidencial	Sensible para el negocio	Datos financieros, planes estratégicos, registros de empleados, listas de clientes
Restringido	Mayor sensibilidad	PII de clientes, credenciales, claves de cifrado, datos de salud/pago

Plantilla de Política de Clasificación de Datos

# [COMPANY NAME] Data Classification Policy

**Effective date:** [DATE]
**Owner:** [SECURITY CHAMPION]

## Purpose

This policy ensures we protect data appropriately based on its sensitivity. 
Not all data is equal — we apply stronger controls to more sensitive data.

## Classification levels

### Public
**Definition:** Information that can be freely shared outside the company.

**Examples:**
- Published blog posts and marketing content
- Public website content
- Open source code repositories
- Press releases

**Handling rules:**
- No special handling required
- Can be posted publicly
- Can be emailed to anyone

---

### Internal
**Definition:** Information for internal use that isn't sensitive but shouldn't 
be public.

**Examples:**
- Internal documentation and wiki
- Company org chart
- Meeting notes (non-sensitive topics)
- Internal announcements
- Non-sensitive Slack conversations

**Handling rules:**
- Share only with employees and approved contractors
- Don't post publicly
- Use company email and approved tools for sharing
- No special encryption required

---

### Confidential
**Definition:** Sensitive business information that could harm the company 
if disclosed.

**Examples:**
- Financial reports and projections
- Business strategies and roadmaps
- Employee compensation data
- Customer lists and contracts
- Source code (proprietary)
- Vendor contracts and pricing
- Internal security reports

**Handling rules:**
- Share only on need-to-know basis
- Use company-approved tools only (no personal email)
- Don't store on personal devices
- Password-protect if sending externally
- Don't discuss in public places

---

### Restricted
**Definition:** Highly sensitive data requiring maximum protection. Unauthorized 
disclosure could cause severe harm.

**Examples:**
- Customer personally identifiable information (PII)
- Payment card data
- Health information
- Passwords and encryption keys
- Authentication tokens and API secrets
- Security vulnerabilities (before patched)
- Legal matters and investigations

**Handling rules:**
- Access strictly limited to those who need it
- Encrypt at rest and in transit
- Never in email attachments (use secure sharing)
- Never on personal devices
- Log all access where possible
- Report any suspected exposure immediately
- Special handling for disposal (secure delete)

---

## Classifying new data

When creating or receiving new data:

1. **Consider the impact of exposure:**
   - Could it harm customers? → Restricted or Confidential
   - Could it harm the business? → Confidential
   - Is it just internal? → Internal
   - Can anyone see it? → Public

2. **When in doubt, classify higher** and ask Security Champion

3. **Mark classified documents** when practical:
   - Documents: Add classification to header/footer
   - Files: Include classification in filename (e.g., "Q4-financials-CONFIDENTIAL.xlsx")
   - Emails: Add classification to subject when sending Confidential/Restricted

---

## Handling by channel

| Channel | Public | Internal | Confidential | Restricted |
|---------|--------|----------|--------------|------------|
| **Company email** | ✓ | ✓ | ✓ (internal only) | ✗ (use secure share) |
| **Personal email** | ✓ | ✗ | ✗ | ✗ |
| **Company Slack** | ✓ | ✓ | ✓ (private channels) | ✗ |
| **Google Drive (company)** | ✓ | ✓ | ✓ (restricted sharing) | ✓ (encrypted, limited) |
| **Personal cloud storage** | ✓ | ✗ | ✗ | ✗ |
| **Printed documents** | ✓ | ✓ | Secure disposal | Secure disposal, limited printing |
| **External sharing** | ✓ | ✗ | Approved recipients, encrypted | Case-by-case approval |

---

## Data retention and disposal

| Classification | Retention | Disposal method |
|---------------|-----------|-----------------|
| Public | No limit | Normal deletion |
| Internal | [X years] or as needed | Normal deletion |
| Confidential | [X years] per legal/business need | Secure delete, shred paper |
| Restricted | Minimum necessary, per regulation | Secure delete, verified shred |

---

## Questions

Contact [SECURITY CHAMPION] at [EMAIL] with questions about classification 
or handling specific data.

Dónde almacenar y gestionar las políticas

Las políticas son inútiles si nadie las puede encontrar. Elija un enfoque de almacenamiento que se adapte a la cultura de su empresa.

Opciones de almacenamiento

Enfoque	Pros	Contras	Ideal para
Repositorio Git	Control de versiones, revisión de PR para cambios, amigable para desarrolladores, rastro de auditoría	El personal no técnico no puede editarlo fácilmente	Equipos con predominio de ingeniería
Notion	Fácil de editar, buena búsqueda, aspecto profesional	Historial de versiones limitado, la exportación es torpe	La mayoría de las pequeñas empresas
Confluence	Se integra con Jira, buenos permisos	Puede volverse desordenado, más lento	Empresas que ya usan Atlassian
Google Docs	Todos lo conocen, fácil de compartir	Se desorganiza rápidamente, búsqueda deficiente	Inicio rápido, equipos muy pequeños
SharePoint	Ecosistema Microsoft, buenos permisos	Complejo, a menudo no querido	Empresas con Microsoft
Herramienta GRC dedicada (Vanta, Drata, Secureframe)	Lista para cumplimiento, plantillas, recopilación de evidencia	$$$, excesivo para lo básico	Preparación para SOC 2/ISO 27001

Gestión de políticas basada en Git

Para empresas tecnológicas, almacenar políticas en Git tiene ventajas reales:

policies/
├── README.md                    # Index of all policies
├── acceptable-use-policy.md
├── incident-response-plan.md
├── data-classification.md
├── playbooks/
│   ├── ransomware.md
│   ├── compromised-account.md
│   └── data-breach.md
└── templates/
    ├── incident-log.md
    └── postmortem.md

Beneficios:

• Los cambios requieren revisión de PR (rastro de auditoría)
• Las diferencias muestran exactamente qué cambió
• Los empleados ya conocen Git
• Fácil de enlazar desde repositorios de código
• Se renderizan bien en GitHub/GitLab

Herramientas:

• Use Markdown para las políticas
• Renderice con MkDocs, Docusaurus o GitBook
• Configure CODEOWNERS para requerir la aprobación del Security Champion
• Enlace desde el manual del empleado y los documentos de incorporación

Hacer que las políticas sean encontrables

Dondequiera que almacene las políticas:

1. Fuente única de verdad — Una ubicación, no dispersa por unidades
2. Enlace desde la incorporación — Todo nuevo empleado debe saber dónde viven las políticas
3. Marcador en Slack — Fije la carpeta de políticas en los canales relevantes
4. La búsqueda funciona — Pruebe que las personas puedan encontrar políticas buscando palabras clave
5. Mantenga la URL estable — No mueva las políticas; los marcadores se rompen

Versioning de políticas

Rastree qué cambió y cuándo:

## Version History

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | 2024-01-15 | Initial release | [Name] |
| 1.1 | 2024-03-22 | Added remote work section | [Name] |
| 2.0 | 2024-06-01 | Major revision for SOC 2 | [Name] |

Si usa Git, su historial de commits es su historial de versiones.

Adaptar las políticas a su empresa

Las plantillas son puntos de partida, no productos finales. Así es como personalizarlas:

Alineación tecnológica

Reemplace las referencias genéricas de herramientas con su stack real:

Término genérico	Herramienta de su empresa
"Correo de empresa"	Gmail, Outlook 365, etc.
"Compartición de archivos aprobada"	Google Drive, Dropbox Business, etc.
"Chat de empresa"	Slack, Teams, etc.
"VPN"	Su solución específica de VPN
"Gestor de contraseñas"	Passwork u su solución elegida

Ajuste cultural

Ajuste el tono y la rigurosidad:

• Startup con cultura informal: Más conversacional, menos secciones formales
• B2B con clientes empresariales: Más formal, secciones detalladas de cumplimiento
• Primero remoto: Más énfasis en la seguridad del trabajo remoto
• Con predominio de desarrolladores: Audiencia técnica, puede usar términos técnicos

Requisitos regulatorios

Añada secciones basadas en sus necesidades de cumplimiento:

• GDPR: Derechos de los sujetos de datos, plazos de notificación de brechas
• HIPAA: Manejo de PHI, requisitos de asociados comerciales
• PCI DSS: Protección de datos de titulares de tarjetas
• SOC 2: Documentación de controles

Personalizaciones comunes

Situación	Personalización
Empresa completamente remota	Amplíe la sección de trabajo remoto, requisitos de seguridad en casa
BYOD permitido	Requisitos detallados para dispositivos personales
Manejo de datos de pago	Requisitos específicos de PCI DSS
Equipo internacional	Consideraciones multijurisdiccionales
Sector altamente regulado	Lenguaje específico de cumplimiento

Implementación de políticas

Escribir políticas es la mitad del trabajo. Lograr que las personas las sigan es la otra mitad.

Lista de verificación de implementación

1. Obtenga la aprobación del liderazgo — Las políticas no significan nada sin el respaldo ejecutivo
2. Anuncie con contexto — Explique el por qué, no solo el qué
3. Haga las políticas encontrables — Ubicación central, no enterradas en correos
4. Requiera reconocimiento — Confirmación con firma o casilla de verificación
5. Capacite en los puntos clave — No espere que las personas lean cada palabra
6. Responda preguntas — Horario de oficina o canal de preguntas y respuestas
7. Aplique consistentemente — Las primeras violaciones importan

Plantilla de anuncio

Subject: New Security Policies — Action Required by [DATE]

Team,

We're rolling out three security policies that define how we protect company 
and customer data. These aren't bureaucracy for bureaucracy's sake — they're 
our answer to "what should I do when..."

**The policies:**
1. Acceptable Use Policy — What's allowed with work computers and data
2. Incident Response Plan — What to do when something goes wrong
3. Data Classification — How to handle different types of information

**What you need to do:**
1. Read the policies: [LINK TO POLICIES]
2. Sign the acknowledgment: [LINK TO FORM]
3. Complete by: [DATE]

**Key takeaways** (if you read nothing else):
- Enable MFA on everything
- Report suspicious stuff to #security-incidents
- Don't put Restricted data (customer PII, passwords) in email
- Lock your computer when you walk away

I'll hold a Q&A session on [DATE] at [TIME] — bring your questions. 
Or ask anytime in #security-questions.

[YOUR NAME]

Mantener las políticas vivas

Las políticas se convierten en documentos archivados a menos que las mantenga activamente:

• Revisión anual — Actualice para nuevas herramientas, amenazas cambiantes, lecciones aprendidas
• Disparadores de incidentes — Actualice el PRI después de cada incidente significativo
• Incorporación de nuevos empleados — Incluya la revisión de políticas en la primera semana
• Capacitación de actualización — Recordatorio anual de los puntos clave
• Seguimiento de excepciones — Revise las excepciones aprobadas para detectar patrones

Errores comunes

1. Copiar sin personalizar — Políticas que hacen referencia a herramientas que no usa
2. Demasiado larga — Nadie lee una PUA de 30 páginas
3. Demasiado vaga — "Use el buen juicio" no es accionable
4. Sin aplicación — Las reglas sin consecuencias se convierten en sugerencias
5. Sin proceso de excepciones — Las personas ignoran las reglas que no pueden seguir
6. Lenguaje legalista — Los empleados ignoran el denso lenguaje jurídico
7. Establecer y olvidar — Las políticas se vuelven obsoletas rápidamente
8. Sin capacitación — Asumir que las personas leerán y entenderán por sí solas
9. Comenzar con todo — Mejor tener 3 políticas sólidas que 10 borradores
10. No involucrar a los interesados — Políticas que no reflejan cómo se trabaja realmente

Taller: cree sus políticas

Parte 1: Política de Uso Aceptable

Tiempo: 2-3 horas

1. Recopile información:

   • Revise sus herramientas y sistemas actuales
   • Hable con TI/DevOps sobre las prácticas de seguridad actuales
   • Consulte a RRHH sobre las directrices existentes para empleados
   • Note cualquier requisito de cumplimiento

2. Redacte la política:

   • Use la plantilla anterior como punto de partida
   • Reemplace todos los marcadores [ENTRE CORCHETES]
   • Añada reglas específicas de la empresa
   • Elimine las secciones que no aplican

3. Revise:

   • Haga que alguien fuera del equipo la lea para verificar la claridad
   • Consulte con el departamento legal si tiene asesor
   • Obtenga la aprobación del liderazgo

Parte 2: Plan de Respuesta a Incidentes

Tiempo: 3-4 horas

1. Defina su equipo:

   • ¿Quién es el Líder del incidente? ¿El sustituto?
   • ¿Quién gestiona la investigación técnica?
   • ¿Quién gestiona la comunicación?
   • Obtenga números de teléfono para contacto fuera del horario laboral

2. Personalice el plan:

   • Actualice la lista de contactos con su gente
   • Ajuste los niveles de severidad a su contexto
   • Añada sus herramientas específicas y métodos de acceso
   • Incluya sus contactos externos (seguros, legal)

3. Pruebe los conceptos básicos:

   • ¿Todos saben cómo reportar un incidente?
   • ¿Puede contactar a los miembros del equipo de respuesta fuera del horario laboral?
   • ¿Tiene acceso a los sistemas necesarios?

Parte 3: Clasificación de Datos

Tiempo: 1-2 horas

1. Haga inventario de sus datos:

   • Datos de clientes: ¿qué tipos, dónde se almacenan?
   • Datos de negocio: ¿financieros, estratégicos, de RRHH?
   • Datos técnicos: ¿credenciales, configuraciones?

2. Clasifique sus principales tipos de datos:

   • Asigne cada uno a Público/Interno/Confidencial/Restringido
   • Note dónde se almacena cada tipo

3. Defina las reglas de manejo:

   • ¿Qué herramientas se pueden usar para cada nivel?
   • ¿Quién puede acceder a cada nivel?
   • ¿Cuánto tiempo retener?

Artefactos a producir

Después de este taller, debería tener:

• Política de Uso Aceptable completada (2-3 páginas)
• Plan de Respuesta a Incidentes completado (3-5 páginas)
• Política de Clasificación de Datos completada (1-2 páginas)
• Formulario de reconocimiento para los empleados
• Borrador del anuncio de implementación
• Ubicación de las políticas (página de wiki, carpeta de unidad compartida)

Preguntas de autoevaluación

1. ¿Cuáles son las tres políticas esenciales que toda empresa debería tener?
2. ¿Por qué las políticas deben ser breves (menos de 5 páginas)?
3. ¿Cuál es la diferencia entre datos Confidenciales y Restringidos?
4. ¿Quién debería estar en un equipo de respuesta a incidentes de una pequeña empresa?
5. ¿Cuándo debe notificar a los clientes sobre un incidente de seguridad?
6. ¿Por qué es importante un postmortem sin culpas?
7. ¿Con qué frecuencia deben revisarse y actualizarse las políticas?
8. ¿Qué debe hacer si un empleado se niega a seguir la PUA?
9. ¿Por qué incluir el "por qué" en las políticas?
10. ¿Cuál es el primer paso cuando sospecha de un incidente?

Cómo explicar esto al liderazgo

El argumento: "Necesitamos tres documentos centrales: qué pueden hacer los empleados con los recursos de la empresa, qué hacer cuando algo sale mal y cómo manejar diferentes tipos de datos. Estos nos protegen legalmente, nos ayudan a responder más rápido a los incidentes y a menudo son requeridos por clientes y aseguradoras."

El ROI:

• Respuesta a incidentes más rápida (horas vs. días de confusión)
• Protección legal si un empleado se porta mal
• Requerido por la mayoría de las pólizas de seguro cibernético
• Solicitado por clientes B2B durante revisiones de seguridad
• Base para cualquier cumplimiento futuro (SOC 2, etc.)

La solicitud: "Necesito 2-3 horas para redactar estos, revisión del liderazgo y un anuncio de la empresa que obligue al reconocimiento. Inversión de tiempo total de la empresa: quizás 30 minutos por empleado para leer y firmar."

El riesgo de no hacerlo: "Ahora mismo, si tenemos una brecha, nadie sabe exactamente qué hacer. Lo estaríamos improvisando a las 2 AM. Y si un empleado hace algo estúpido con datos de la empresa, no tenemos ninguna política documentada que demuestre que sabía que no debía hacerlo."

Conclusión

Las políticas que nadie lee no protegen a nadie. Una política de uso aceptable de una página que todos han firmado supera a un documento de cumplimiento de 40 páginas que vive en una unidad compartida.

Escriba para las personas que seguirán la política, no para el auditor que la revisará.

Qué sigue

Siguiente: comunicación y evangelismo de seguridad — cómo hablar de seguridad de maneras que hagan que las personas realmente cambien su comportamiento.