# Ciberseguridad para pymes y empresas en México: qué revisar primero y en qué orden

> Ciberseguridad para pymes en orden de prioridad: MFA, respaldos que restauran, parches, correo, servicios expuestos, nube, accesos y plan de incidentes.

Autor: Samuel Hinojosa (CEO & Founder, WITS) · Actualizada: 2026-10-25 · https://security.wits.mx/guias/ciberseguridad-pymes/

## ¿Por dónde empieza la ciberseguridad de una pyme?

Empieza por lo que más ataques detiene con menos esfuerzo: verificación en dos pasos (MFA) en correo y nube, respaldos que sí se restauran y actualizaciones al día. Después revisas qué tienes expuesto a internet, quién tiene acceso a qué y qué harías el día de un incidente. Ese orden coincide con las guías públicas de CISA, NIST y CIS.

No hace falta inventar el método. La agencia de ciberseguridad de Estados Unidos publica [Cyber Essentials](https://www.cisa.gov/resources-tools/resources/cyber-essentials), una guía para dirigentes de empresas pequeñas organizada en seis elementos: tú como líder, tu equipo, tus sistemas, tu entorno digital, tus datos y tu respuesta a una crisis. Como primeros pasos recomienda respaldos automáticos, MFA empezando por los usuarios administradores y de acceso remoto, y aplicar parches sin demora.

El Center for Internet Security llama a su punto de partida «higiene cibernética esencial»: el [Grupo de Implementación 1 de los CIS Controls](https://www.cisecurity.org/controls/implementation-groups/ig1), un conjunto de 56 salvaguardas pensado para organizaciones pequeñas. Y NIST mantiene un [rincón de ciberseguridad para pequeñas empresas](https://www.nist.gov/itl/smallbusinesscyber) con guías por tema: ransomware, phishing, MFA, nube y respuesta a incidentes. Lo que sigue es ese material aterrizado a cómo opera una empresa mexicana típica.

## ¿Qué revisar primero, en orden de prioridad?

| # | Qué revisar | Señal de que está bien |
|---|---|---|
| 1 | Cuentas y MFA | Correo, nube, banca y repositorios piden un segundo factor; nadie comparte contraseñas |
| 2 | Respaldos | Hay una copia fuera del alcance de un atacante y alguien ya probó restaurarla |
| 3 | Actualizaciones | Sistemas operativos, PHP, CMS y equipos de red en versiones con soporte |
| 4 | Correo del dominio | SPF, DKIM y DMARC publicados y DMARC en una política que rechaza suplantaciones |
| 5 | Servicios expuestos | Solo lo necesario responde desde internet; nada de bases de datos ni SSH abiertos a todos |
| 6 | Configuración de la nube | Cuenta raíz protegida, registro de actividad encendido y alertas que alguien lee |
| 7 | Quién tiene acceso | Lista de accesos al día; los que ya se fueron no conservan llaves ni usuarios |
| 8 | Plan de incidentes | Una página que dice a quién llamar, qué apagar y dónde están los respaldos |

### 1. Cuentas y MFA

Muchos incidentes en empresas pequeñas empiezan con una contraseña robada, reutilizada o adivinada. Activa MFA primero en el correo, porque desde ahí se recuperan todas las demás cuentas, y luego en la consola de la nube, el banco, el dominio y los repositorios de código. Prefiere una app de autenticación o una llave física sobre el SMS.

### 2. Respaldos que sí se restauran

Un respaldo que nunca se ha restaurado es una suposición. Un atacante con acceso a tu red puede borrar o cifrar las copias que encuentre ahí, así que al menos una debe vivir fuera de la red principal o en un almacenamiento que no se pueda modificar. Agenda una prueba de restauración y anota cuánto tardó: ese dato es tu tiempo real de recuperación.

### 3. Actualizaciones

Muchas de las fallas que se explotan en ataques reales ya tenían parche publicado. CISA publica el [catálogo de vulnerabilidades explotadas](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) y es buena regla priorizar lo que aparece ahí. Pon atención a lo que ya no recibe soporte: un sistema hecho hace años en PHP 7.4 no va a recibir parche oficial. En [las alertas de la semana](https://security.wits.mx/alertas/) resumimos qué versiones están en riesgo y qué hacer.

### 4. Correo: SPF, DKIM y DMARC

Sin estos registros, cualquiera puede mandar correos que parecen salir de tu dominio y pedir un pago a tus clientes. [SPF](https://www.rfc-editor.org/rfc/rfc7208.html) dice qué servidores pueden enviar por ti, DKIM firma cada mensaje y [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) se apoya en ambos para decirle al receptor qué hacer con lo que falla y mandarte reportes. Empieza en modo de monitoreo, revisa los reportes y sube la política cuando sepas que tu correo legítimo pasa.

### 5. Servicios expuestos a internet

Haz la lista de todo lo que responde desde fuera: sitio web, VPN, escritorio remoto, paneles de administración, puertos de base de datos. Cada uno es una puerta. Lo que no necesita estar abierto se cierra o se pone detrás de una VPN, y lo que sí, se actualiza y se protege. Es el mismo principio de la [guía de hardening de servidores](https://security.wits.mx/guias/hardening-servidores/).

### 6. Configuración de la nube

La nube no viene segura por defecto: viene configurable. Lo típico que encontramos es la cuenta raíz sin MFA, llaves de acceso de hace años, almacenamiento público por error y servicios de detección encendidos que avisan a un correo que nadie abre. Si tu sistema vive en AWS, la [guía de auditoría de seguridad AWS](https://security.wits.mx/guias/auditoria-seguridad-aws/) explica qué revisar control por control.

### 7. Quién tiene acceso a qué

Proveedores que ya terminaron, exempleados, el desarrollador que armó el sistema en 2019: todos pueden seguir con usuario, llave SSH o token en tu código. Haz el inventario de accesos una vez al trimestre y quita lo que nadie puede justificar. Cada persona con su propia cuenta y solo con los permisos que usa.

### 8. Plan de incidentes

No necesitas un manual de cien páginas. Necesitas una página impresa con a quién llamar, quién decide apagar un sistema, dónde están los respaldos y las contraseñas de emergencia, y cómo avisar a clientes. CISA lo resume como limitar el daño y recuperar la operación normal lo antes posible.

## ¿Cuánto de esto puede hacer tu equipo sin ayuda?

Bastante. Los puntos 1, 2, 7 y 8 dependen más de disciplina que de conocimiento técnico. Una lista para esta semana:

- Activar MFA en el correo de todos y en las cuentas de administrador.
- Restaurar un archivo y una base de datos desde el respaldo, y anotar cuánto tardó.
- Revisar la versión de PHP de tu sitio con el [chequeo gratis](https://security.wits.mx/chequeo-php/).
- Pedir a quien administra tu dominio el estado de SPF, DKIM y DMARC.
- Hacer la lista de personas y proveedores con acceso y quitar a quien ya no lo necesita.
- Imprimir la página del plan de incidentes y dejarla donde se encuentre.

Los puntos 3, 5 y 6 sí piden a alguien técnico: saber qué versiones corren de verdad, qué puertos están abiertos y cómo está configurada la nube no se ve desde una oficina. Ahí es donde una revisión externa ahorra semanas.

## ¿Cuándo conviene una auditoría externa?

Cuando tienes sistemas propios o una cuenta de nube que nadie ha revisado desde que se lanzó, cuando un cliente grande te manda un cuestionario de seguridad, cuando preparas [una auditoría ISO 27001](https://security.wits.mx/guias/iso-27001-auditoria/) o cuando ya tuviste un susto. También antes de contratar un pentest: si no has cerrado lo básico, el informe se llena de hallazgos que una revisión encuentra mucho antes. Lo explicamos en [pentest vs. auditoría](https://security.wits.mx/guias/pentest-vs-auditoria/).

> **Qué hace Security OS** Security OS, la plataforma de [WITS](https://security.wits.mx/), audita tu nube (AWS a fondo), tus repositorios, tu código y tus servidores con permisos de solo lectura. Te entrega los hallazgos por prioridad, prepara cada corrección con su reversa y la aplica solo con tu autorización. Cada cierre queda con evidencia antes y después. No es un SOC 24/7, no certifica y no hace pentest.

Un primer paso de cinco segundos: el chequeo lee solo la respuesta pública de tu portada. Úsalo con dominios que te pertenecen o que administras. [Revisar mi PHP gratis](https://security.wits.mx/chequeo-php/)

## Preguntas frecuentes

**¿Qué es lo primero que debe hacer una pyme en ciberseguridad?**

Activar la verificación en dos pasos (MFA) en el correo y en las cuentas de administrador, y comprobar que los respaldos se pueden restaurar. Son las dos medidas que más ataques detienen con menos esfuerzo.

**¿Mi empresa es demasiado pequeña para ser objetivo?**

No. Muchos ataques son automáticos: buscan versiones vulnerables, contraseñas filtradas y servicios abiertos sin importar el tamaño de la empresa. Ser pequeño solo significa tener menos gente para notar el ataque.

**¿Qué guía seguir si no tengo equipo de TI?**

Cyber Essentials de CISA está escrita para dirigentes de empresas pequeñas y el Grupo de Implementación 1 de los CIS Controls reúne 56 salvaguardas esenciales. Las dos son gratuitas.

**¿Para qué sirven SPF, DKIM y DMARC?**

Para que nadie pueda mandar correos que parezcan salir de tu dominio. SPF autoriza servidores, DKIM firma los mensajes y DMARC le dice al receptor qué hacer con los que no pasan y te envía reportes.

**¿Cada cuánto debo probar mis respaldos?**

Por lo menos cada trimestre y después de cualquier cambio grande en tus sistemas. Mide cuánto tarda la restauración completa: ese es tu tiempo real para volver a operar.

**¿Un antivirus es suficiente?**

No. El antivirus protege el equipo, pero no evita que alguien entre con una contraseña robada, que tu nube tenga almacenamiento público o que un servidor corra una versión sin soporte.

**¿Security OS sustituye a un área de seguridad?**

No es un SOC 24/7. Audita y vigila nube, repositorios, código y servidores, prepara las correcciones y deja evidencia de cada cierre. Para muchas pymes cubre lo técnico que hoy nadie revisa.

## Fuentes

- [CISA: Cyber Essentials](https://www.cisa.gov/resources-tools/resources/cyber-essentials)
- [NIST: Small Business Cybersecurity Corner](https://www.nist.gov/itl/smallbusinesscyber)
- [CIS Controls: Implementation Group 1 (IG1)](https://www.cisecurity.org/controls/implementation-groups/ig1)
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [IETF RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208.html)
- [IETF RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html)