# MacLockdown — Caso de Negocio & Posicionamiento Final

**Versión:** 1.1  
**Fecha:** 2026-03-16  
**Estado:** ✅ Base estratégica aprobada para packaging, pricing y messaging

---

## 1. Tesis Central

MacLockdown no vende hardening como fin en sí mismo.

Vende:

> **Postura de seguridad medible, accionable y demostrable en macOS (a nivel de dispositivo)**

---

## 2. Posicionamiento

### Interno / estratégico

> **Mac Security Posture Platform**

Uso recomendado:

- roadmap
- documentación estratégica
- inversores
- partners

No exponer aún como mensaje principal mientras el producto siga siendo single-device y local-first.

### Externo / actual

> **Measure, harden and prove your Mac security posture**

Razones:

- claro
- creíble
- técnico sin sonar cerrado
- no sobrepromete compliance total

---

## 3. Arquitectura de Producto

### Basic — Visibility

Pregunta que responde:

> **¿Qué riesgo tengo hoy?**

Incluye:

- scan manual
- score
- controles esenciales
- export simple

### Professional — Remediation

Pregunta que responde:

> **¿Cómo reduzco mi riesgo ahora?**

Incluye:

- hardening automático
- perfiles `Hardened` y `Paranoid`
- logs
- historial
- re-scan

### Compliance — Evidence

Pregunta que responde:

> **¿Cómo demuestro control y continuidad?**

Incluye:

- benchmark `CIS` / `PCI DSS`
- export auditoría
- historial de postura
- evolución de benchmarks
- soporte prioritario

---

## 4. Paranoid — Posicionamiento Final

`Paranoid` no debe tratarse como plan comercial separado.

Debe tratarse como:

> **Modo operativo avanzado dentro de Professional**

Mensaje recomendado:

> **Paranoid mode: advanced hardening for high-risk environments**

Propiedades:

- alta fricción operativa
- restricciones agresivas
- pensado para usuarios con mayor conciencia de amenaza

Requisito de UX:

> “This mode may impact usability and break workflows”

---

## 5. Continuous Security Posture

No vender como buzzword genérica.

Aplicación concreta:

### En Professional

> **Stay hardened as macOS evolves**

Significa:

- re-scan
- persistencia
- adaptación a cambios del sistema

### En Compliance

> **Track and prove your security posture over time**

Significa:

- historial
- evolución
- evidencia continua

---

## 6. Ajuste de Claim

Evitar:

> “One-click operationalization of security standards”

Usar:

> **One-click application of device-level security controls based on industry standards**

Porque:

- no promete compliance total
- mantiene precisión técnica
- sigue siendo comercialmente fuerte

---

## 7. Diferenciador Real

MacLockdown no compite por:

- cantidad de checks
- complejidad técnica

Compite por:

> **Reducir riesgo en el dispositivo, rápido y de forma verificable**

---

## 8. Narrativa Comercial

### Basic

> **See your security gaps in minutes**

### Professional

> **Fix them automatically and reduce your attack surface**

### Compliance

> **Prove your security posture over time**

Pitch corto:

> **We help you measure, harden and prove your Mac security posture — in minutes**

---

## 9. Riesgos que este posicionamiento evita

- vender `Paranoid` como “3 checks más”
- vender `Compliance` como “reportes bonitos”
- usar `platform` demasiado pronto
- sobreprometer cumplimiento total

---

## 10. Decisión Ejecutiva

- Mantener modelo de 3 capas
- Reposicionar `Paranoid` como modo
- Tratar `Compliance` como capa de continuidad y evidencia
- Ajustar claims hacia `device-level security controls`
- Mantener la narrativa de riesgo + remediación + evidencia

---

## 11. Extensión futura de Compliance

Como evolución de roadmap, `Compliance` puede crecer desde benchmarks base (`CIS`, `PCI DSS`) hacia marcos regulatorios sectoriales con mayor valor comercial.

Línea inicial sugerida:

- Chile: `CMF` y referencias como `RAN 20-10`
- Brasil: regulaciones de ciberseguridad y resiliencia del `Banco Central do Brasil`
- Colombia: lineamientos y circulares de la `Superintendencia Financiera de Colombia`
- México: disposiciones y reporting de incidentes bajo `CNBV` y normativa financiera aplicable
- Argentina: lineamientos y requerimientos del `BCRA` en ciberseguridad para entidades financieras

Regla de producto:

- tratar estos marcos como backlog estratégico
- no prometer cobertura hasta validar alcance regulatorio exacto por país y tipo de entidad
- mantener el lenguaje de `device-level evidence`, no de cumplimiento total
