Desde el 15 de marzo de 2026, un certificado de seguridad no puede durar más de 200 días. Desde marzo de 2027 serán 100. Desde marzo de 2029, 47.
Si tú renuevas el tuyo una vez al año, como se hizo siempre, tu sitio va a aparecer marcado como no seguro 165 días al año. Y en cuanto entre el siguiente tramo, 265.
Esa fecha ya pasó y casi nadie la vio. Es un buen ejemplo de lo que este artículo intenta hacer: la mayoría de los sitios pequeños no se caen porque alguien los ataque. Se caen porque venció algo, faltó una copia o el dominio estaba a nombre de otra persona.
Lo que sigue son esos fallos, con las fechas y los plazos exactos, y un plan de una tarde para cerrarlos todos.
La respuesta corta
- Averigua hoy a nombre de quién está tu dominio. Es el único error de esta lista que puede ser irreversible.
- Pon tres fechas en el calendario: dominio, hosting y certificado, con aviso un mes antes. Y activa la renovación automática de las tres.
- El certificado ya no se renueva a mano. Tiene que renovarse solo, y hay que comprobar que lo está haciendo.
- Un respaldo que nunca restauraste es una suposición. Restaura uno, completo, en un lugar de pruebas, una vez.
- Revisa cuántas cuentas de administrador tienes. En WordPress, un administrador puede instalar plugins, editar archivos, crear usuarios y borrar el sitio. Un editor no puede nada de eso.
- Nunca actualices sin poder volver atrás, y nunca un viernes.
- No guardes datos personales que no necesitas. Lo que no guardas no se puede filtrar, y la ley te obliga a avisar si se filtra.
- Da de alta tu sitio en Search Console y pon un monitor de caídas. Las dos cosas son gratis y son la diferencia entre enterarte hoy o dentro de tres semanas.
Lo que de verdad tumba un sitio pequeño
La palabra «seguridad» empuja a imaginar a alguien intentando entrar. Y sí, eso pasa, y en el artículo sobre plugins vimos con cifras que pasa mucho.
Pero cuando uno recoge los casos reales de sitios pequeños que se quedaron sin sitio, el reparto es distinto. La mayoría no fueron ataques.
Fueron un dominio que venció porque el aviso llegó a un correo que nadie abre. Un desarrollador que registró el dominio a su nombre y dejó de contestar. Una actualización que rompió el carrito un viernes y un respaldo que resultó estar incompleto. Una cuenta de administrador de un becario que salió hace dos años. Un certificado que caducó y dejó el sitio con un candado roto durante una semana antes de que alguien lo notara.
Los ocho errores, ordenados por lo que cuesta repararlos
| Error | Qué tan reversible es |
|---|---|
| El dominio está a nombre de otra persona | Puede ser irreversible |
| El dominio venció | Recuperable dentro de un plazo, con cargo |
| El certificado venció | Horas, pero el sitio sale marcado mientras tanto |
| El respaldo nunca se probó | Solo lo descubres el día que lo necesitas |
| Hay cuentas de administrador de más | Quince minutos, si te acuerdas de revisarlo |
| Actualizaste sin poder volver atrás | Restaurando, si hay respaldo |
| Guardas datos personales de más | Consecuencias legales, no técnicas |
| No te enteraste | Multiplica el daño de todos los anteriores |
Fíjate en lo que tienen en común los tres primeros: son fechas y son papeles. No hay nada técnico en ninguno.
Y fíjate en algo más incómodo: el orden de esta tabla es prácticamente el inverso del orden en que los trata un artículo típico de seguridad web, que empieza por el certificado y las contraseñas y nunca llega a la propiedad del dominio.
Por qué la lista genérica no funciona
«Usa contraseñas fuertes» es un consejo correcto que no le dice a nadie qué abrir primero. El problema de las listas de ocho puntos genéricos no es que estén mal: es que no tienen fechas, no tienen orden y no tienen forma de comprobar si ya lo hiciste.
Este artículo intenta lo contrario. Cada error trae qué comprobar, dónde se comprueba y cuánto tarda. Al final hay un plan de tres horas que los cierra todos y un calendario anual para que no se vuelvan a abrir.
Si estás empezando y quieres el mapa completo de tropiezos del arranque, más allá de lo técnico, está en errores comunes al empezar un negocio en línea.
Error 1 · El dominio no está a tu nombre
Empezamos por el peor, que además es el que menos se menciona.
Tu dominio es lo único de tu sitio que no puedes reconstruir. El diseño se rehace, el contenido se reescribe, el hosting se cambia en una tarde. El dominio, si es de otra persona, es de otra persona.
Quién es el titular y por qué es la única figura que importa
En el registro de un dominio hay varios contactos, y se parecen lo bastante como para confundirlos: hay un contacto administrativo, uno técnico, uno de facturación. Ninguno de esos manda.
El que manda es el titular del registro, el registrante. Es quien puede autorizar una transferencia, quien puede cambiar los demás contactos y a quien, en la práctica, pertenece el dominio.
El caso típico y doloroso: contratas a alguien para que te haga el sitio, esa persona compra el dominio «para agilizar», y lo registra con su propio nombre y su propio correo. Todo funciona durante tres años. Y un día esa persona deja de contestar, o cierra su negocio, o simplemente cambia de correo y se olvida de renovar.
No hay truco técnico que resuelva eso.
Cómo comprobarlo hoy, en diez minutos
Tres pasos:
- Busca el registro público de tu dominio. Hay buscadores de WHOIS gratuitos; también tu propio registrador te muestra el titular en el panel de tu cuenta. Lo que buscas es el nombre y el correo del registrante.
- Comprueba que el correo del titular es uno que tú abres. No el del despacho que te hizo la página, ni uno que ya no usas. Los avisos de vencimiento llegan ahí y a ningún otro lado.
- Comprueba que tú tienes acceso a la cuenta del registrador, no solo al panel del hosting. Son dos cuentas distintas y mucha gente solo tiene la segunda.
Si el registro está protegido con privacidad y no ves los datos, entra al panel de tu registrador: ahí siempre aparece.
Qué hacer si no eres tú
Con calma y por escrito, mientras la relación sea buena:
- Pide que te transfieran la titularidad, no que «te den acceso». Son cosas distintas: el acceso se quita, la titularidad no.
- Si el dominio está en la cuenta del proveedor, pide la transferencia a una cuenta tuya en el registrador que prefieras. Suele necesitar un código de autorización y suele tardar unos días.
- Deja constancia por correo, no por mensaje. El día que haya un desacuerdo, lo que existe es lo que está escrito.
Y una regla para la siguiente vez: el dominio lo compras tú, con tu tarjeta y tu correo, y le das acceso a quien te ayude. Cuesta lo mismo y cambia quién manda. El criterio general para decidir qué le entregas a un proveedor y qué te quedas está en cómo elegir un proveedor confiable.
Un matiz honesto: hay proveedores serios que administran dominios de sus clientes y lo hacen bien, con contratos claros. El problema no es que el proveedor lo administre; es que el titular sea él y tú no lo sepas.
Error 2 · El calendario: tres fechas que apagan el sitio
Tres cosas de tu sitio tienen fecha de vencimiento: el dominio, el hosting y el certificado de seguridad. Las tres vencen en días distintos, las tres avisan a correos que a lo mejor no abres, y cualquiera de las tres apaga el sitio.
Este es el error más evitable de la lista y también uno de los más frecuentes.
Lo que pasa exactamente cuando vence un dominio
La Política de Recuperación de Registros Vencidos de ICANN fija plazos concretos, y conviene conocerlos antes de necesitarlos.
Primero, los avisos. La política exige que «Registrars must send you at least two renewal reminder notices before the domain name expires, one approximately one month prior to expiration and the second approximately one week prior to expiration» (traducción nuestra: al menos dos recordatorios antes del vencimiento, uno aproximadamente un mes antes y otro aproximadamente una semana antes), más al menos un aviso adicional dentro de los cinco días posteriores al vencimiento.
Tres avisos. Y los tres van al correo del titular del registro, que es exactamente el punto del error anterior. Si ese correo es el de alguien que ya no te contesta, los tres avisos existen y ninguno te llega.
Después del vencimiento, la secuencia:
| Etapa | Cuánto dura | Qué puedes hacer |
|---|---|---|
| Periodo de gracia de renovación | De 1 a 45 días, según el registrador | Renovar normalmente |
| Interrupción del DNS | Hasta 8 días antes del borrado | El sitio ya está apagado |
| Periodo de redención | 30 días tras el borrado | Recuperarlo, con un cargo adicional |
| Liberación | Después | El dominio vuelve al mercado |
El detalle que casi nadie sabe
Mira la segunda fila otra vez. La política dice: «The ERRP requires registrars to disrupt the domain name’s DNS service for up to 8 days before deleting the domain name» (traducción nuestra: obliga a los registradores a interrumpir el servicio de DNS hasta ocho días antes de borrar el dominio).
Es decir: el registrador está obligado a apagarte el sitio antes de borrar el dominio, precisamente para que te des cuenta. Es una medida sensata y produce un efecto que confunde a mucha gente: llamas a tu hosting porque «se cayó el sitio», y el hosting está perfectamente bien. Lo que pasó fue que el dominio venció hace semanas.
Si alguna vez te pasa que el sitio deja de resolver de golpe y el hosting jura que todo está en orden, revisa la fecha de vencimiento del dominio antes que ninguna otra cosa.
El periodo de redención y lo que cuesta
Si el dominio llega a borrarse, todavía hay 30 días. La política «requires all generic TLD registries to offer a Redemption Grace Period («RGP») of 30 days immediately following the deletion of a domain name registration» (traducción nuestra: exige a los registros de dominios genéricos ofrecer un periodo de redención de treinta días inmediatamente después del borrado).
Recuperarlo ahí es posible y tiene un costo: la documentación de ICANN señala que el registrador puede cobrar una cuota por ese servicio, a veces llamada cuota de redención. No publica una cifra, y varía por registrador, así que no vamos a inventarla. Lo que sí se puede decir con seguridad es que es varias veces lo que habría costado renovar a tiempo, y que ese mes lo pasas con el sitio apagado.
Pasados los 30 días, el dominio se libera y cualquiera puede registrarlo. Hay empresas dedicadas exclusivamente a capturar dominios que se liberan. Si el tuyo tenía tráfico, no va a estar disponible mucho tiempo.
El hosting y el certificado
Las otras dos fechas se comportan distinto y conviene saber cómo.
El hosting normalmente se suspende, no se borra de inmediato. Tus archivos siguen ahí un tiempo y el sitio deja de cargar. Suele recuperarse pagando, pero pregunta cuánto tiempo conserva tus datos un proveedor suspendido: es una de las diez preguntas de cómo elegir un hosting para una tienda en línea, y la respuesta cambia mucho de una empresa a otra.
El certificado no suspende nada: simplemente deja de ser válido, y el navegador pone una advertencia de sitio no seguro entre tu cliente y tu página. Nadie compra atravesando esa pantalla. Y esa fecha es la que cambió este año, así que tiene sección propia.
Las tres renovaciones, juntas
Lo que yo haría con estas tres fechas, en este orden:
- Activa la renovación automática de las tres. Es lo único que las resuelve de verdad. Y comprueba que la tarjeta que tienen guardada no está por vencer, que es la forma más tonta de que la renovación automática falle.
- Anótalas de todos modos en el calendario, con aviso un mes antes. La renovación automática falla más de lo que debería, y el aviso es lo que te hace mirar.
- Que las tres apunten a un correo que tú abras. No el de la agencia, no el que usabas en 2019.
- Revísalas con el resto de tus cargos recurrentes. Son tres suscripciones como cualquier otra, y el método para cazarlas está en qué gastos deberías revisar cada mes para ahorrar más.
Y una advertencia sobre el plazo largo: contratar el dominio a cinco años no te exime de mirar. Lo que hace es que la fecha esté tan lejos que nadie recuerde que existe.
Error 3 · Renovar el certificado a mano ya no es posible
Esta es la parte del artículo que más urge y la que ningún texto en español menciona.
El certificado de seguridad es lo que hace que tu dirección empiece por https y que el navegador no ponga una advertencia. Durante años duró un año y se renovaba una vez al año. Eso se acabó, y el cambio ya está en marcha.
El calendario que ya empezó
El organismo que fija las reglas de los certificados aprobó en 2025 un calendario de reducción progresiva de la vida máxima. Según la publicación de DigiCert sobre ese calendario, los tramos son estos:
| Desde | Vida máxima del certificado | Renovaciones al año |
|---|---|---|
| Hasta el 15 de marzo de 2026 | 398 días | 1 |
| 15 de marzo de 2026 | 200 días | 2 |
| 15 de marzo de 2027 | 100 días | 4 |
| 15 de marzo de 2029 | 47 días | 8 |
El primer tramo lleva más de seis meses en vigor.
Y por el lado de las autoridades certificadoras gratuitas, el movimiento es el mismo o más rápido. Let’s Encrypt anunció en diciembre de 2025 que reduce sus certificados de 90 a 45 días, en tres fases: certificados de 45 días en su perfil nuevo desde el 13 de mayo de 2026, de 64 días en el perfil clásico desde el 10 de febrero de 2027, y de 45 días en el perfil clásico desde el 16 de febrero de 2028.
La cuenta
Aquí está el problema, en un número.
Si tu certificado dura como máximo 200 días y tú lo renuevas una vez al año, hay 165 días al año en los que no tienes certificado válido. Ciento sesenta y cinco días con el navegador advirtiendo a tus visitantes que tu sitio no es seguro.
| Tramo | Vida máxima | Días al año sin certificado válido si renuevas una vez al año |
|---|---|---|
| Hasta marzo de 2026 | 398 días | 0 |
| Desde marzo de 2026 | 200 días | 165 |
| Desde marzo de 2027 | 100 días | 265 |
| Desde marzo de 2029 | 47 días | 318 |
No es una proyección ni un supuesto: es una resta. Y en 2029, un sitio con renovación anual estaría roto el 87% del año.
Lo que dice quien los emite
Conviene citar a la fuente directamente, porque es tajante. Let’s Encrypt escribe, sobre la renovación manual: «Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes» (traducción nuestra: no se recomienda renovar certificados a mano, porque habrá que hacerlo con más frecuencia conforme se acorte su vida).
Y añade una advertencia que le va a tocar a mucha gente que cree tenerlo automatizado: «renewing at a hardcoded interval of 60 days will no longer be sufficient» (traducción nuestra: renovar a un intervalo fijo de sesenta días dejará de ser suficiente). Es decir, no basta con que esté automatizado: tiene que estar automatizado con el intervalo correcto, y muchos guiones antiguos tienen un número fijo escrito dentro.
Qué hacer hoy con el certificado
Tres comprobaciones, quince minutos:
- Mira cuándo vence el tuyo. Haz clic en el candado de la barra del navegador, en tu propio sitio. Ahí aparece la fecha. Si falta más de 200 días, algo está mal en lo que estás viendo.
- Averigua quién lo renueva. Casi todos los hostings modernos lo renuevan solos y no hay nada que hacer. Pero eso hay que confirmarlo, no suponerlo: pregúntalo por escrito al soporte, con esas palabras: «¿el certificado de mi dominio se renueva automáticamente y cada cuánto?».
- Si lo renuevas tú, deja de hacerlo así. Migra a una emisión automática, y si tienes un guion propio con un intervalo escrito a mano, revisa ese número. La lógica general de convertir una tarea recurrente en algo que no dependa de tu memoria está en cómo automatizar tareas repetitivas.
Y una cuarta, preventiva: pon una alerta que te avise si el certificado está por vencer. Varios monitores de caídas lo incluyen gratis, y lo vemos más adelante.
Por qué los están acortando
Una pregunta razonable, porque parece una molestia gratuita.
La idea de fondo es que un certificado es una afirmación sobre quién controla un dominio, y esa afirmación envejece. Si un dominio cambia de manos o una clave se filtra, un certificado de trece meses sigue siendo válido durante mucho tiempo después. Acortar la vida reduce esa ventana y, de paso, obliga a que todo el ecosistema automatice, que era el objetivo de fondo.
No hay que estar de acuerdo con la decisión para tener que convivir con ella. Pero conviene saber que la dirección es clara: cada tramo es más corto que el anterior, y desde enero de 2026 Let’s Encrypt ofrece a todo el mundo certificados que duran «160 hours, just over six days», poco más de seis días. Esos son para quien ya tenga la renovación completamente automatizada, que es justo el punto.
Error 4 · El respaldo que nunca restauraste
Este error tiene una característica desagradable: solo se descubre el día que importa.
Mucha gente tiene respaldos. Mucha menos gente ha restaurado uno. Y entre esas dos cosas hay una distancia que solo se mide en el peor momento posible, cuando el sitio está caído, hay pedidos pendientes y alguien está esperando en el teléfono.
Las cuatro preguntas de un respaldo
No es «¿tienes respaldos?». Son estas cuatro:
- ¿Cada cuánto se hacen? Para un sitio que vende, diarios es el mínimo. Con respaldos semanales puedes perder seis días de pedidos.
- ¿Qué incluyen? Un respaldo de archivos sin base de datos no sirve para recuperar una tienda: los pedidos, los productos y los usuarios viven en la base de datos. Comprueba que incluye las dos cosas.
- ¿Dónde se guardan? Si viven dentro del mismo servidor que respaldan, no son un respaldo: son una copia en el mismo lugar. Si hay un problema serio con el proveedor, o una disputa de pago que suspende tu cuenta, se van juntos.
- ¿Cuánto tiempo se conservan? De poco sirve un respaldo de ayer si el problema empezó hace tres semanas y no lo notaste. Un mes de historial es un mínimo razonable.
El ensayo de restauración
Y la quinta pregunta, que es la que casi nadie contesta: ¿alguna vez restauraste uno?
El ensayo toma una tarde y se hace una vez:
- Descarga un respaldo completo a tu computadora. No lo restaures desde el panel: descárgalo. Quieres comprobar que el archivo existe, que se puede bajar y que pesa lo que debería.
- Levántalo en un entorno de pruebas, no en tu sitio. Casi todos los hostings ofrecen uno, y si el tuyo no, un servidor local en tu computadora sirve igual para esto.
- Navega el resultado como si fueras un cliente. Portada, una entrada, una página de producto, agregar al carrito. Es donde aparecen los problemas: las imágenes que no estaban, la configuración que no se guardó, el plugin que se desactivó solo.
- Cronometra cuánto te tomó. Ese número es tu tiempo real de recuperación, y es lo que vas a poder prometerle a alguien el día malo.
Si el ensayo sale bien, ya no tienes una suposición: tienes un respaldo. Si sale mal, acabas de descubrirlo un martes cualquiera en lugar de un viernes a las siete de la tarde.
Qué respaldar, además del sitio
Tres cosas que no están en el respaldo del hosting y que también hacen falta el día malo:
- Los accesos. La cuenta del registrador, la del hosting, la del sitio, la de la pasarela de pago. En un lugar al que puedas llegar desde el celular.
- La configuración que vive fuera. Los registros de DNS, la configuración de la pasarela, las claves de las integraciones. Una captura de pantalla de cada pantalla de configuración, guardada con fecha, resuelve la mayoría de los casos.
- Una copia de tu catálogo en un formato que se lea solo. Si tu tienda corre sobre WooCommerce, exporta los productos a una hoja de cálculo cada tanto; la lógica de qué depende de la plataforma y qué no está en la comparativa de WooCommerce contra otras plataformas.
Error 5 · Las llaves: cuentas de administrador de más
Cada cuenta de administrador de tu sitio es una copia completa de tus llaves. No una llave parecida: la misma llave.
Y las cuentas de administrador se acumulan solas. El que hizo el diseño, la agencia que llevó las redes un semestre, el becario del año pasado, el plugin que creó una cuenta de servicio, la cuenta de prueba que alguien hizo para ver algo.
Qué puede hacer un administrador que un editor no
WordPress publica la lista exacta de permisos de cada rol en su documentación de roles y capacidades, y conviene mirarla con números en la mano.
Un administrador tiene 52 permisos. Un editor, 26. Y no se solapan a medias: el editor no tiene ni uno solo que el administrador no tenga, así que la diferencia son 26 permisos que el administrador tiene de más.
Entre esos 26 están estos:
| Permiso | Qué significa |
|---|---|
install_plugins | Instalar cualquier plugin, de cualquier origen |
edit_files | Editar archivos del sitio desde el navegador |
edit_plugins, edit_themes | Modificar el código que corre en tu sitio |
update_core | Actualizar WordPress entero |
create_users, delete_users, promote_users | Crear cuentas, borrarlas y ascenderlas |
manage_options | Cambiar cualquier ajuste del sitio |
delete_site | Borrar el sitio |
Y esto es lo que sí puede hacer un editor, que suele ser todo lo que la gente necesita en realidad: publicar y editar cualquier entrada y cualquier página, incluidas las de otros; moderar comentarios; gestionar categorías; subir archivos.
Léelo otra vez pensando en las personas que tienen acceso a tu sitio. La que escribe el blog necesita ser editora. La que sube productos, según el caso, puede necesitar un rol de tienda. Administrador necesita ser quien administra, y esa suele ser una sola persona.
Si quieres entender mejor cómo está armada la plataforma por dentro, está en qué es WordPress y por qué sigue siendo útil.
La revisión de cuentas, en quince minutos
- Abre la lista de usuarios y filtra por administradores. Es el primer número que quieres ver: cuántos hay.
- Por cada uno, contesta dos preguntas: ¿sé quién es? ¿necesita instalar plugins y borrar el sitio? Si la respuesta a la primera es no, o la segunda es no, hay que hacer algo.
- Baja de rol antes de borrar. Convertir a alguien en editor es reversible y no rompe la autoría de lo que ya publicó. Borrar una cuenta te obliga a decidir qué pasa con su contenido.
- Las cuentas de gente que se fue, se eliminan, reasignando su contenido a otra cuenta. No se dejan «por si acaso»: esa es exactamente la cuenta que nadie revisa durante tres años.
- Revisa también quién tiene acceso a las otras cuentas: registrador, hosting, pasarela de pago, correo. La seguridad de tu sitio es la de la cuenta más descuidada de esa lista.
El desarrollador que se fue
Es el caso más común y el más incómodo, porque casi nunca hay mala fe: simplemente la relación terminó y nadie cerró las puertas.
Lo que hay que hacer cuando se acaba un trabajo, y conviene hacerlo el mismo día:
- Cambia las contraseñas de hosting, registrador, sitio y pasarela de pago. No «revoca el acceso»: cambia las contraseñas.
- Baja o elimina su cuenta de usuario en el sitio.
- Revisa si dejó cuentas de servicio o accesos de aplicaciones conectadas.
- Comprueba el titular del dominio. Otra vez, porque es el que no se arregla después.
Esto no es desconfianza: es higiene. Se hace igual con la mejor de las relaciones, y se hace mejor cuando la relación todavía es buena, porque así la conversación es un trámite y no un conflicto.
Error 6 · Actualizar sin red
Ya tratamos con detalle la parte de las actualizaciones en qué son los plugins y cuáles sí valen la pena, incluida la cuenta de cuánto tardas en aplicar un parche según tu costumbre. Aquí va solo lo que falta: cómo actualizar sin que te tumbe el sitio.
Cuatro reglas y ninguna es técnica:
1. Nunca actualices sin poder volver atrás. Un respaldo de hoy, probado, antes de tocar nada. Si no lo tienes, no es momento de actualizar: es momento de hacer el respaldo.
2. Nunca un viernes, ni en temporada alta, ni antes de una campaña. Los problemas de una actualización aparecen cuando alguien intenta comprar, y eso puede tardar horas en pasar. Quieres estar disponible cuando pase.
3. El plugin central del negocio, aparte. La tienda, el sistema de reservas, el constructor de páginas: esos se actualizan a mano, con tiempo, habiendo leído qué cambió, y de preferencia primero en un entorno de pruebas.
4. Después de actualizar, navega el sitio como cliente. Portada, una página de producto, agregar al carrito, llegar hasta el pago. El panel de administración puede verse perfecto con la tienda rota.
Y una quinta que no es una regla sino una observación: la mayoría de la gente que tiene miedo de actualizar es porque no tiene respaldo probado. Resuelto eso, el miedo desaparece solo, y con él la costumbre mucho más peligrosa de no actualizar nunca.
Error 7 · Guardar datos personales que no necesitas
Antes de nada: esto no es asesoría legal. Es un mapa de por dónde pasa la línea, con los artículos citados para que los revises con tu abogado.
Casi cualquier sitio recoge datos personales. Un formulario de contacto, los comentarios, un boletín, un chat, y desde luego una tienda. Y cada dato que guardas es a la vez una obligación y un riesgo: lo que no guardas no se puede filtrar.
Las seis cosas que debe tener tu aviso de privacidad
La Ley Federal de Protección de Datos Personales en Posesión de los Particulares, publicada el 20 de marzo de 2025, lo enumera en su artículo 15. El aviso «deberá contener, al menos, la siguiente información»:
| Fracción | Qué exige |
|---|---|
| I | La identidad y domicilio del responsable |
| II | Los datos que se tratan, identificando los sensibles |
| III | Las finalidades, distinguiendo las que requieren consentimiento |
| IV | Las opciones y medios para limitar el uso o divulgación |
| V | Los mecanismos para ejercer los derechos ARCO |
| VI | Cómo se comunicarán los cambios al aviso |
Toma tu aviso de privacidad actual y compáralo con esa tabla, punto por punto. Es media hora y es la revisión legal más barata que vas a hacer este año. Muchos avisos de sitios pequeños son una plantilla copiada que no incluye ni el domicilio ni el procedimiento de cambios.
La obligación que casi nadie conoce
Esta es la que sorprende a todo el mundo.
El artículo 19 de la misma ley establece: «Las vulneraciones de seguridad ocurridas en cualquier fase del tratamiento de datos personales que afecten de forma significativa los derechos patrimoniales o morales de las personas titulares le serán informadas de forma inmediata por el responsable, a fin de que pueda tomar las medidas correspondientes a la defensa de sus derechos».
Léelo despacio. Si tu sitio sufre una filtración que afecte de forma significativa los derechos de tus clientes, tienes la obligación de informarles, y de hacerlo de forma inmediata. No cuando lo hayas investigado del todo. No cuando tengas lista una explicación cómoda.
Y hay una consecuencia práctica que se deriva sola: para poder avisar, necesitas saber que pasó y a quién le pasó. Es decir, necesitas saber qué datos guardas, dónde, y desde cuándo. Un sitio que no sabe qué información tiene no puede cumplir esa obligación aunque quiera.
Y la de las medidas de seguridad
El artículo 18 es la base de todo lo demás: «Todo responsable deberá establecer y mantener medidas de seguridad administrativas, técnicas y físicas que permitan proteger los datos personales contra daño, pérdida, alteración, destrucción o el uso, acceso o tratamiento no autorizado».
Fíjate en las tres palabras: administrativas, técnicas y físicas. La ley no te pide un cortafuegos: te pide un conjunto de medidas de tres tipos. Revisar quién tiene cuenta de administrador es una medida administrativa. Tener respaldos probados protege contra pérdida y destrucción. Este artículo entero es, mirado así, una lista de medidas de los tres tipos.
El mismo artículo añade un criterio que conviene tener presente: «Los responsables no adoptarán medidas de seguridad menores a aquellas que mantengan para el manejo de su información». En otras palabras, no puedes cuidar los datos de tus clientes peor de lo que cuidas los tuyos.
El dato que no guardas
De aquí sale el consejo más útil de toda la sección, y es una reducción, no una adición:
- Apaga el almacenamiento de los formularios si con el correo te basta. Muchos plugins de formularios guardan cada envío en la base de datos por defecto y para siempre. Si tú lees el correo y contestas, esa copia solo suma riesgo.
- Borra lo que ya no necesitas. Envíos de hace cuatro años, cuentas de clientes que nunca compraron, listas de correo de campañas que terminaron.
- No pidas lo que no vas a usar. Cada campo de más en un formulario es un dato que tienes que proteger, y encima baja la tasa de respuesta.
- Sé consciente de a dónde viaja. Si un plugin o un servicio externo procesa esos datos, eso abre preguntas propias que desarrollamos en las mejores herramientas de IA para emprendedores, con la misma ley aplicada a otro caso.
Y una nota práctica que suele ahorrar dinero: falta el reglamento de esta ley, así que varios detalles de cómo se cumple están todavía por precisar. Eso no suspende las obligaciones del texto, y es una razón más para revisarlo con un abogado en vez de con un artículo.
Error 8 · No enterarte
De todos los errores de esta lista, este es el que multiplica a los demás.
Un certificado vencido detectado en una hora es una molestia. Detectado en tres semanas son tres semanas de visitantes viendo una advertencia. Un sitio comprometido descubierto el mismo día se limpia; descubierto cuando ya te bajó Google es otra historia.
Search Console te lo dice, gratis
Google mantiene un informe de problemas de seguridad para los sitios dados de alta en Search Console. Según su documentación, detecta tres categorías: contenido hackeado, que define como el «contenido colocado en tu sitio sin tu permiso debido a vulnerabilidades de seguridad»; software malicioso y no deseado; e ingeniería social, que es el contenido que «engaña a los visitantes para que hagan algo peligroso».
Y lo que está en juego, en sus palabras: «Las páginas o sitios afectados por un problema de seguridad pueden aparecer con una etiqueta de advertencia en los resultados de búsqueda o una página de advertencia intersticial en el navegador cuando un usuario intenta visitarlas».
Dar de alta el sitio toma quince minutos, es gratis, y Google manda avisos por correo. Si tienes un sitio y no lo has hecho, es probablemente la tarea de mejor relación entre esfuerzo y beneficio de todo este artículo.
El monitor de caídas
La segunda pieza. Un servicio que abre tu sitio cada pocos minutos desde fuera y te avisa cuando deja de responder.
Hay opciones gratuitas suficientes para un sitio pequeño. Lo que conviene configurar:
- Que revise la portada y una página interna, no solo el dominio. Un sitio puede responder en la raíz y tener el catálogo roto.
- Que te avise por un canal que mires, no solo por correo.
- Que vigile el vencimiento del certificado, si lo ofrece. Varios lo incluyen y cierra el error 3 por el otro lado.
Es diez minutos de configuración y convierte «hace tres días que estaba caído» en «llevaba cuatro minutos caído».
Las señales de que algo pasó
Aunque no tengas ninguna de las dos cosas anteriores, hay señales que conviene reconocer:
- El sitio de pronto va mucho más lento sin que hayas cambiado nada. Puede ser mil cosas, y las más comunes no son un ataque; el diagnóstico ordenado está en cómo mejorar la velocidad de tu sitio web. Pero conviene descartar lo demás.
- Aparecen entradas, páginas o usuarios que no creaste.
- Tu sitio redirige a otro lado, pero solo desde el celular o solo para quien llega de una búsqueda. Es un patrón conocido y muy difícil de ver desde tu propia computadora.
- Te llega correo rebotado de mensajes que tú no enviaste.
- El tráfico de búsqueda cae de golpe sin explicación.
- Tu hosting te escribe por consumo de recursos anormal.
Ninguna de esas señales es concluyente por sí sola. Todas merecen que abras Search Console y mires.
Qué hacer el día que pasa
Sin adrenalina y en orden:
- Confirma que es real. Ábrelo desde el celular con datos móviles, no desde tu wifi.
- Revisa las tres fechas. Dominio, hosting, certificado. Es la causa más probable y la más rápida de descartar.
- Mira la página de estado de tu hosting. Si hay un incidente general, ya lo saben.
- Abre el ticket con datos, no con enojo: hora exacta, mensaje de error, desde dónde lo probaste, si cambiaste algo en las últimas veinticuatro horas.
- Avisa por tus otros canales. Un mensaje diciendo que el sitio está temporalmente fuera cuesta dos minutos y salva clientes.
- No toques nada en caliente. Reinstalar cosas a ver si se arregla rompe más de lo que arregla.
- Si hubo acceso no autorizado a datos de personas, esa es otra conversación, y empieza por el artículo 19 de la sección anterior y por tu abogado.
- Escribe qué pasó cuando termine. Media página: qué falló, cuánto duró, qué lo habría evitado.
El plan de una tarde
Todo lo anterior cabe en una tarde. No en un proyecto, no en una consultoría: en una tarde, hecho por ti, con el orden que sigue.
| # | Tarea | Tiempo |
|---|---|---|
| 1 | Comprobar quién figura como titular del dominio | 10 min |
| 2 | Activar la renovación automática del dominio y del hosting | 10 min |
| 3 | Poner las tres fechas en el calendario con aviso a un mes | 10 min |
| 4 | Revisar y reducir las cuentas de administrador | 15 min |
| 5 | Comprobar que el certificado se renueva solo | 15 min |
| 6 | Descargar un respaldo completo y guardarlo fuera del servidor | 20 min |
| 7 | Restaurar ese respaldo en un entorno de pruebas | 45 min |
| 8 | Dar de alta el sitio en Search Console | 15 min |
| 9 | Poner un monitor de caídas | 10 min |
| 10 | Revisar el aviso de privacidad contra el artículo 15 | 30 min |
| Total | 180 min · 3 horas |
Si valúas tu hora en 250 pesos, la tarde entera cuesta 750 pesos de tu tiempo, una sola vez. A 400 pesos la hora, 1,200.
El orden importa
Las tres primeras van juntas y al principio por una razón: son las que evitan el daño irreversible. Si solo tienes media hora, haz esas tres y deja el resto para otro día.
La número 7 es la larga y es la única que no se puede saltar. Todas las demás son comprobaciones; esa es la que convierte una suposición en un hecho. Si te queda poco tiempo, sacrifica cualquier otra antes que esta.
Y la número 10 es la única que quizá necesite a alguien más. Compárala tú contra las seis fracciones del artículo 15, anota qué falta, y lleva esa lista a tu abogado en vez de llegar con «revísame el aviso». La conversación es mucho más corta y mucho más barata.
Lo que no está en el plan
Tres cosas que este artículo deliberadamente no te pide que hagas:
- Contratar un servicio de seguridad. Puede tener sentido más adelante; no antes de haber hecho las diez tareas de arriba, que son gratuitas y cierran más superficie.
- Instalar plugins nuevos. Ninguna de las diez tareas necesita uno, salvo quizá el respaldo si no tienes.
- Cambiar de hosting. Si tu proveedor es el problema, se descubre haciendo estas tareas; no antes.
El calendario anual
Lo de arriba se hace una vez. Esto es lo que evita que se vuelva a abrir.
| Cada cuánto | Qué se revisa | Tiempo |
|---|---|---|
| Semana | Actualizaciones del plugin central del negocio | 5 min |
| Mes | Search Console, y que los respaldos se estén haciendo | 15 min |
| Seis meses | Cuentas de administrador · restaurar un respaldo de prueba · titular y fechas del dominio, hosting y certificado | 90 min |
| Año | Aviso de privacidad y limpieza de datos que ya no necesitas | 60 min |
Suma unas once horas al año, que repartidas dan menos de una hora al mes. Y hay dos fechas fijas que conviene tener apuntadas desde ahora:
- 15 de marzo de 2027: la vida máxima del certificado baja de 200 a 100 días.
- 15 de marzo de 2029: baja a 47.
Si tu renovación es automática, esas dos fechas no te van a pedir nada. Si no lo es, son los dos días en que se rompe.
La forma de que un calendario así se sostenga no es la fuerza de voluntad: es que las cuatro filas vivan en el mismo lugar donde vive el resto de tu semana, con recordatorio. El hábito, no la lista, es lo que lo hace funcionar, y ese es el tema de cómo organizar tu día.
Tres razones para desconfiar de esta lista
Primero: ordenamos los errores por criterio, no por datos. La tabla de los ocho errores está ordenada por lo difícil que es repararlos, y eso sí se puede argumentar. Pero la afirmación de que estos ocho son los que más sitios pequeños tumban es nuestra lectura, no una estadística: no existe un registro público de por qué se apagan los sitios chicos, precisamente porque casi ninguno lo reporta. Si alguien te da un porcentaje sobre eso, pregúntale de dónde salió.
Segundo: las fechas de los certificados son lo único que aquí caduca solo, y caduca pronto. El 15 de marzo de 2027 toda la sección 3 cambia de cifras. Están tomadas del calendario aprobado por el organismo que fija esas reglas, y los calendarios se pueden modificar. Antes de planear con ellas, confírmalas.
Tercero: este artículo no cubre los ataques, y los ataques existen. Aquí tratamos lo administrativo porque es lo que nadie escribe y lo que más sitios apaga. La otra mitad —vulnerabilidades, parches, la ventana de exposición— está en el artículo de plugins, con cifras. Los dos juntos son el mapa; ninguno de los dos lo es por separado.
Preguntas frecuentes
¿Cuál es el error más grave que puedo cometer con mi sitio web?
Que el dominio no esté a tu nombre. Es el único de la lista que puede ser irreversible: el diseño se rehace, el contenido se reescribe y el hosting se cambia en una tarde, pero si el titular del registro es otra persona, el dominio es de esa persona. Compruébalo hoy en el panel de tu registrador o en un buscador público de WHOIS, y fíjate en el registrante, no en el contacto administrativo ni en el técnico.
¿Qué pasa exactamente si se me vence el dominio?
Tu registrador debe mandarte al menos dos avisos antes de que venza, uno aproximadamente un mes antes y otro una semana antes, y uno más dentro de los cinco días posteriores. Después suele haber un periodo de gracia de entre 1 y 45 días para renovarlo. Antes de borrarlo, el registrador está obligado a interrumpir el servicio de DNS hasta ocho días, así que el sitio se apaga mientras el dominio todavía es tuyo. Si llega a borrarse, hay treinta días de periodo de redención para recuperarlo pagando un cargo. Después se libera.
¿Por qué mi sitio se cayó si el hosting dice que todo está bien?
Revisa la fecha de vencimiento del dominio antes que ninguna otra cosa. Es la causa que más confunde: el registrador está obligado a cortar el DNS hasta ocho días antes de borrar un dominio vencido, así que el sitio deja de resolver mientras el servidor sigue funcionando perfectamente. Las otras dos candidatas rápidas son el hosting suspendido por falta de pago y el certificado caducado.
¿Cada cuánto hay que renovar el certificado SSL ahora?
Depende del tramo del calendario. Desde el 15 de marzo de 2026, un certificado no puede durar más de 200 días; desde el 15 de marzo de 2027 serán 100 y desde el 15 de marzo de 2029, 47. Si lo renuevas una sola vez al año, tienes 165 días al año sin certificado válido hoy y 265 a partir de 2027. La respuesta práctica es que ya no se renueva a mano: tiene que renovarse solo, y hay que comprobar que lo está haciendo.
¿Cómo sé si mi certificado se renueva automáticamente?
Haz clic en el candado de la barra del navegador, en tu propio sitio, y mira la fecha de vencimiento. Si falta más de 200 días, algo no cuadra con lo que estás viendo. Después pregúntale al soporte de tu hosting con estas palabras: «¿el certificado de mi dominio se renueva automáticamente y cada cuánto?». Y si tienes un guion propio que lo renueva, revisa que no tenga escrito a mano un intervalo fijo: los de sesenta días van a dejar de servir.
¿Cuántas cuentas de administrador debería tener mi sitio?
Las menos posibles, y normalmente una. Según la documentación de WordPress, un administrador tiene 52 permisos y un editor 26; entre la diferencia están instalar plugins, editar archivos, crear y borrar usuarios y borrar el sitio completo. La persona que escribe el blog necesita ser editora. Administrador necesita ser quien administra. Revisa la lista dos veces al año, baja de rol antes de borrar, y elimina las cuentas de quien ya no trabaja contigo reasignando su contenido.
¿Cómo sé si mi copia de seguridad sirve?
Restaurándola. Es la única forma y toma una tarde: descarga un respaldo completo a tu computadora, levántalo en un entorno de pruebas y navégalo como si fueras un cliente, hasta el carrito. Cronometra cuánto tardaste, porque ese es tu tiempo real de recuperación. Comprueba además que incluye la base de datos y no solo los archivos, y que se guarda fuera del mismo servidor que respalda.
¿Cómo me entero de que hackearon mi sitio?
Con dos cosas gratuitas que se configuran en veinticinco minutos entre las dos. Search Console de Google mantiene un informe de problemas de seguridad que detecta contenido hackeado, software malicioso e ingeniería social, y te avisa por correo; su documentación advierte que las páginas afectadas pueden aparecer con una etiqueta de advertencia en los resultados de búsqueda. Y un monitor de caídas que abra tu sitio cada pocos minutos desde fuera. Sin ninguna de las dos, la forma habitual de enterarse es que te avise un cliente.
¿Tengo que avisar a mis clientes si hubo una filtración de datos?
La ley mexicana de datos personales establece en su artículo 19 que las vulneraciones de seguridad que afecten de forma significativa los derechos patrimoniales o morales de las personas titulares les serán informadas de forma inmediata por el responsable. El responsable eres tú. Cómo se aplica eso a tu caso concreto lo contesta un abogado, pero la consecuencia práctica es clara: para poder avisar necesitas saber qué datos guardas y dónde, y eso se prepara antes, no después.
¿Necesito contratar un plugin o un servicio de seguridad?
Puede tener sentido, pero no antes de hacer las diez tareas de la tarde, que son gratuitas y cierran más superficie de la que cierra cualquier producto. Siete de los ocho errores de este artículo no se resuelven con software: se resuelven con fechas en el calendario, una revisión de cuentas y un respaldo probado. Un servicio de seguridad encima de eso suma; en lugar de eso, no.
¿Cuánto tiempo al año me lleva mantener esto?
La puesta a punto inicial son tres horas, una sola vez. Después, unas once horas al año, que son menos de una al mes: cinco minutos por semana para las actualizaciones del plugin central, quince minutos al mes para mirar Search Console y los respaldos, noventa minutos cada seis meses para las cuentas y el ensayo de restauración, y una hora al año para el aviso de privacidad y la limpieza de datos. La parte semanal es la que más pesa en el total, y es la de cinco minutos.
Fuentes y metodología
Todas las fuentes se consultaron el 25 de septiembre de 2026. En este tema hay una fecha que conviene tener presente por encima de todas: el 15 de marzo de 2027 cambian las cifras de la sección de certificados. Antes de planear con ellas, confírmalas en la fuente.
Dominios
- ICANN, «5 Things every Domain Name Registrant should know about ICANN’s Expired Registration Recovery Policy»:
- «Registrars must send you at least two renewal reminder notices before the domain name expires, one approximately one month prior to expiration and the second approximately one week prior to expiration», más al menos un aviso adicional dentro de los cinco días posteriores al vencimiento.
- El periodo de gracia de renovación automática: «a 1-45-day period during which you may renew an expired domain name».
- «The ERRP requires all generic TLD registries to offer a Redemption Grace Period («RGP») of 30 days immediately following the deletion of a domain name registration».
- «The ERRP requires registrars to disrupt the domain name’s DNS service for up to 8 days before deleting the domain name».
- ICANN, preguntas frecuentes sobre renovación y vencimiento de dominios: insiste en mantener actualizados los datos de contacto para recibir los avisos, señala que la renovación automática es un servicio que ofrecen la mayoría de los registradores y no una obligación, y menciona que recuperar un dominio en periodo de redención «may result in an additional fee, sometimes referred to as a redemption fee», sin publicar una cifra.
Certificados
- DigiCert, «TLS Certificate Lifetimes Will Officially Reduce to 47 Days», que detalla el calendario aprobado por el CA/Browser Forum en la votación SC-081v3: vida máxima de 398 días hasta el 15 de marzo de 2026, 200 días desde el 15 de marzo de 2026, 100 días desde el 15 de marzo de 2027 y 47 días desde el 15 de marzo de 2029. Los periodos de reutilización de la validación de dominio siguen el mismo calendario hasta 2029, cuando bajan a 10 días.
- CA/Browser Forum, votación SC081v3, que aprueba la «Eventual reduction of maximum validity period from 398 days to 47 days», con los cambios «proposed to occur starting in March 2026 and concluding in March 2029». El desglose por tramos no aparece en el texto de la votación publicado en su sitio, sino en los documentos adjuntos, que no pudimos abrir; por eso citamos los tramos desde la publicación de DigiCert, que es una autoridad certificadora que los está implementando.
- Let’s Encrypt, «Decreasing Certificate Lifetimes to 45 Days», del 2 de diciembre de 2025: pasan de certificados «valid for 90 days» a 45 días, en tres fases —13 de mayo de 2026, 10 de febrero de 2027 y 16 de febrero de 2028—. Sobre la renovación manual: «Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes», y la advertencia de que «renewing at a hardcoded interval of 60 days will no longer be sufficient».
- Let’s Encrypt, «6-day and IP Address Certificates are Generally Available», del 15 de enero de 2026: «These certificates are valid for 160 hours, just over six days», y señalan que quienes «have fully automated their renewal process should be able to switch to short-lived certificates easily».
Roles de usuario
- WordPress, documentación de roles y capacidades: la lista completa de permisos de cada rol. El administrador reúne 52 permisos, incluidos
install_plugins,edit_files,edit_plugins,edit_themes,update_core,create_users,delete_users,manage_optionsydelete_site. El editor reúne 26 y ninguno de ellos está fuera de la lista del administrador.
Detección
- Google, informe de problemas de seguridad de Search Console: detecta contenido hackeado, definido como el «contenido colocado en tu sitio sin tu permiso debido a vulnerabilidades de seguridad»; software malicioso y no deseado; e ingeniería social, «contenido que engaña a los visitantes para que hagan algo peligroso». Y advierte: «Las páginas o sitios afectados por un problema de seguridad pueden aparecer con una etiqueta de advertencia en los resultados de búsqueda o una página de advertencia intersticial en el navegador cuando un usuario intenta visitarlas».
Marco legal
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares, publicada en el Diario Oficial de la Federación el 20 de marzo de 2025:
- Artículo 15: las seis fracciones que debe contener el aviso de privacidad, citadas íntegras en el cuerpo del artículo.
- Artículo 18: «Todo responsable deberá establecer y mantener medidas de seguridad administrativas, técnicas y físicas que permitan proteger los datos personales contra daño, pérdida, alteración, destrucción o el uso, acceso o tratamiento no autorizado», y «Los responsables no adoptarán medidas de seguridad menores a aquellas que mantengan para el manejo de su información».
- Artículo 19: «Las vulneraciones de seguridad ocurridas en cualquier fase del tratamiento de datos personales que afecten de forma significativa los derechos patrimoniales o morales de las personas titulares le serán informadas de forma inmediata por el responsable, a fin de que pueda tomar las medidas correspondientes a la defensa de sus derechos».
Competencia revisada
- GoDaddy Latinoamérica, «Checklist completo: cómo hacer que tu sitio web sea seguro»: entre 2,000 y 2,500 palabras, ocho puntos razonables y bien escritos —HTTPS, actualizaciones, respaldos automáticos, integridad de archivos, cambiar el usuario por defecto, contraseñas fuertes, proteger el dominio y el DNS, y escaneos de malware—, publicados por una empresa que vende hosting, dominios y servicios de seguridad. Ni una sola cifra, ni una sola fecha, ninguna mención al vencimiento del dominio ni a los plazos de ICANN, ninguna al calendario de los certificados, ninguna al titular del dominio, ninguna a los roles de usuario y nada sobre la ley mexicana de datos personales.
Cálculos propios
- Días al año sin certificado válido. Es una resta: 365 menos la vida máxima del certificado en ese tramo. Da 0 con 398 días, 165 con 200, 265 con 100 y 318 con 47. Supone que el titular renueva una sola vez al año, que es la costumbre que el calendario rompe.
- Renovaciones al año. 365 dividido entre la vida máxima del tramo: 0.9, 1.8, 3.7 y 7.8 respectivamente, que en el texto redondeamos a 1, 2, 4 y 8.
- Ventana total desde el vencimiento de un dominio. Hasta 45 días de gracia más 30 de redención, 75 días como máximo, con la advertencia de que el DNS puede cortarse mucho antes.
- Permisos de los roles de WordPress. Conteo propio sobre las listas publicadas en la documentación: 52 para administrador, 26 para editor, 26 de diferencia y ninguno exclusivo del editor.
- El plan de una tarde. Los diez tiempos son estimaciones nuestras de cuánto toma cada tarea a alguien que no lo ha hecho antes. Son supuestos, no mediciones. Suman 180 minutos, y valuados a 250 y 400 pesos la hora dan 750 y 1,200 pesos de tiempo propio.
- El calendario anual suma 5 minutos semanales (260 al año), 15 mensuales (180), 90 cada seis meses (180) y 60 una vez al año: 680 minutos, unas 11.3 horas anuales, que repartidas dan unos 57 minutos al mes.
Limitaciones
- No existe un registro público de por qué se apagan los sitios pequeños. La afirmación de que estos ocho errores son los que más daño hacen es nuestra lectura y no una estadística. La ordenamos por reversibilidad, que sí se puede argumentar, y lo decimos dentro del artículo.
- No publicamos el costo de recuperar un dominio en periodo de redención. ICANN documenta que puede haber un cargo y no publica cifra; varía por registrador. Preferimos decirlo a poner un número de un blog.
- El desglose por tramos del calendario de certificados lo tomamos de una autoridad certificadora, no del texto de la votación del CA/Browser Forum, cuyos documentos adjuntos no pudimos abrir. Las fechas de inicio y fin y el rango de 398 a 47 días sí están en la votación publicada.
- No pudimos consultar el artículo 76 bis de la Ley Federal de Protección al Consumidor, que trata las obligaciones de los proveedores en transacciones por medios electrónicos: el documento en PDF quedó truncado antes de ese artículo. Por eso el artículo no entra en las obligaciones de comercio electrónico, que son materia aparte.
- Falta el reglamento de la ley de datos personales de 2025, que puede precisar cómo se cumplen varias de las obligaciones citadas.
- No recomendamos ni evaluamos ningún servicio concreto de monitoreo, respaldo o seguridad. Damos la función y qué configurar; el producto lo eliges tú.
- Este artículo no contiene enlaces de afiliado y no recibe pago de ningún servicio mencionado.
Aviso. Este artículo es informativo y no constituye asesoría legal. En materia de protección de datos personales, consulta a un abogado antes de tomar decisiones sobre tu negocio.