La seguridad de una página web no debería aparecer como un extra cuando el proyecto ya está terminado. Muchas decisiones importantes se toman antes de escribir una sola línea: quién será propietario del dominio, qué personas tendrán acceso, dónde se guardarán las copias, qué datos recogerán los formularios y quién mantendrá cada componente.
Si estas cuestiones no se incluyen en el presupuesto y en el alcance, suelen quedar en tierra de nadie. La web puede entregarse con buen aspecto, pero sin un procedimiento de actualización, recuperación o retirada de accesos. Incluir requisitos de seguridad desde el principio reduce improvisaciones y permite comparar propuestas con criterios más útiles que el diseño y el precio.
La seguridad empieza con el alcance
No todas las webs necesitan las mismas medidas. Una página informativa, una zona privada y una tienda online manejan riesgos y datos diferentes. El proveedor debería preguntar qué hará la web, quién la administrará y con qué servicios se conectará.
Un alcance inicial debería identificar:
- Funciones públicas y privadas.
- Datos que recibirán los formularios.
- Usuarios y perfiles administrativos.
- Integraciones con pagos, reservas, CRM, correo o analítica.
- Requisitos de disponibilidad y recuperación.
- Responsables del mantenimiento tras la entrega.
Esta información permite decidir controles proporcionados. Instalar herramientas sin conocer el contexto puede dejar riesgos sin tratar o añadir complejidad que nadie mantendrá.
Propiedad y control de los activos
El cliente debería conservar el control de su dominio, alojamiento y propiedades digitales. Un proveedor puede administrarlos mediante permisos delegados, pero la empresa necesita saber dónde están, cómo se renuevan y qué correo permite recuperar cada cuenta.
Antes de contratar, conviene acordar:
- A nombre de quién se registra el dominio.
- Quién controla DNS, alojamiento y CDN.
- Qué cuentas serán propietarias de Analytics, Search Console y Perfil de Empresa.
- Cómo se entregarán archivos, base de datos y documentación.
- Qué ocurrirá con licencias y accesos al finalizar la relación.
Cuentas individuales y privilegios mínimos
Compartir una única contraseña administrativa impide saber quién realizó un cambio y complica la retirada de permisos. Cada persona debería utilizar una cuenta individual con el nivel necesario para su función.
El presupuesto debería indicar si se configurarán perfiles, autenticación multifactor cuando esté disponible y un procedimiento para revisar usuarios. El desarrollador necesita acceso durante el proyecto, pero no todas las personas que publican contenido requieren privilegios de administración.
Actualizaciones y compatibilidad
Una web no queda terminada para siempre. El gestor de contenidos, extensiones, plantilla, servidor e integraciones evolucionan. Es importante definir si el servicio incluye actualizaciones, durante cuánto tiempo y qué pruebas se realizarán.
Una frase como “web actualizable” no equivale a un mantenimiento. Conviene concretar frecuencia, copias previas, comprobaciones posteriores, gestión de incompatibilidades y canal para comunicar incidencias.
Copias que puedan restaurarse
Tener una copia no garantiza una recuperación. El proyecto debería aclarar qué se respalda, con qué frecuencia, durante cuánto tiempo, en qué ubicación y quién verifica la restauración.
En una web dinámica suelen ser necesarios archivos y base de datos. Además, una copia almacenada únicamente en el mismo alojamiento puede quedar afectada por el mismo incidente. La estrategia debe adaptarse al impacto que tendría perder cambios o permanecer varias horas sin servicio.
Formularios y tratamiento de información
Cada campo añadido a un formulario aumenta la información que debe protegerse. Antes de pedir teléfono, documento, currículum o datos de salud, hay que justificar si son necesarios y definir su destino.
El equipo técnico puede aplicar validación, protección contra automatismos, cifrado en tránsito, límites de subida y retención adecuada. Los textos legales, bases jurídicas y obligaciones de protección de datos deben coordinarse con asesoramiento especializado cuando corresponda. Un desarrollador no sustituye al asesor jurídico.
Registro, monitorización y respuesta
Cuando algo falla, se necesita información suficiente para investigar. El registro debe ser útil y proporcionado: accesos administrativos, errores relevantes, cambios y alertas, evitando recopilar datos innecesarios o conservarlos indefinidamente.
También conviene definir a quién se avisa ante una caída, una modificación no autorizada o un posible compromiso. Sin contactos y prioridades, una alerta puede existir y aun así no producir respuesta.
Entrega y documentación
Una entrega profesional puede incluir inventario de componentes, ubicación de copias, usuarios autorizados, renovaciones, integraciones y tareas pendientes. Las contraseñas no deben aparecer en documentos sin protección; es preferible entregarlas mediante un gestor seguro.
La documentación ayuda a mantener la web, cambiar de proveedor y demostrar qué medidas se implantaron. No garantiza ausencia de incidentes, pero reduce la dependencia de la memoria de una sola persona.
Preguntas para comparar presupuestos
- ¿Quién será propietario del dominio y las cuentas?
- ¿Qué medidas de seguridad están incluidas desde el desarrollo?
- ¿Cómo se gestionan usuarios y accesos?
- ¿Qué copias se realizan y cómo se restauran?
- ¿Quién actualiza la web después de publicarla?
- ¿Qué documentación se entrega?
- ¿Cómo se comunica y atiende una incidencia?
Conclusión
Una web segura no se obtiene marcando una casilla al final. Se construye mediante decisiones de arquitectura, acceso, datos, mantenimiento y recuperación tomadas desde el presupuesto.
El servicio Build & Secure de T3chWare integra creación web y medidas técnicas proporcionadas desde el inicio.
Si quieres revisar el alcance de tu próxima web, contacta en T3chWare →
