La forma más rápida de obtener un informe de pentest listo para auditoría para el cumplimiento de SOC 2

La forma más rápida de obtener un informe de pentest listo para auditoría para el cumplimiento de SOC 2 es una plataforma de pruebas de penetración con IA bajo demanda que combine la exploración autónoma con la validación de exploits. Las startups prueban web, API y aplicaciones móviles en conjunto, reciben pruebas deterministas de la explotación y obtienen una Carta de Atestación; se estima que una evaluación Core tarda de 5 a 7 días, y que los alcances mayores requieren de 10 a 20 días.

Cerrar una venta a una gran empresa es uno de los hitos más exigentes para una empresa B2B SaaS en fase inicial. Su equipo pasa meses demostrando el valor del producto, alineando a las partes interesadas y negociando las condiciones comerciales. Entonces, en la última puerta de aprobación, el área de compras de la empresa detiene todo el proceso. Su equipo de gestión de riesgos de terceros (TPRM, por sus siglas en inglés) envía una evaluación de seguridad de proveedores en la que exige un informe independiente de pruebas de penetración y una Carta de Atestación formal con fecha dentro de los últimos doce meses.

Las consultoras de seguridad tradicionales requieren de tres a cinco semanas de plazo para programar la evaluación y facturan entre $15,000 y $40,000 por una evaluación puntual. Para una startup con un margen operativo limitado y una cuota de ventas trimestral urgente, esperar un mes para obtener un hueco de pruebas programado frena el impulso de los ingresos. Por el contrario, ejecutar un escáner de vulnerabilidades automatizado básico y enviar el PDF resultante provoca el rechazo inmediato tanto del área de compras de la empresa como de los auditores de SOC 2.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           FAST-TRACK AUDIT EVIDENCE PIPELINE                            │
└─────────────────────────────────────────────────────────────────────────────────────────┘

   [Target Assets] ──► [Agentic Deep Scan] ──► [Deterministic Proof] ──► [Developer Remediation]
      • Web Apps          • Autonomous Agents     • HTTP Request/Resp        • Actionable Curl PoCs
      • REST/GraphQL      • Contextual Chaining   • Differential Baseline    • Zero Triage Friction
      • iOS & Android     • Logic & Auth Checks   • Low False Positives
                               │
                               ▼
   [1-Click Re-Test] ──► [Finding Review] ────► [Audit Package Export] ──► [Unblock Sales]
      • Risk Rerun Pass     • Named Sign-off      • Attestation Letter (LoA)   • Pass SIG / CAIQ
      • Verified Retest     • Quality Review      • Executive Summary (NDA)    • Close Deals Fast

¿Qué comprueban realmente los equipos de TPRM de las empresas en un informe de pentest?

Los equipos de gestión de riesgos de terceros (TPRM) de las empresas comprueban cuatro criterios principales en un informe de pentest: una Carta de Atestación independiente con fecha dentro de los últimos 12 meses, un alcance multiactivo completo (web, API y aplicaciones móviles), ningún hallazgo de severidad alta o crítica sin resolver y pruebas alineadas con marcos reconocidos (OWASP y NIST SP 800-115).

Cuando los equipos de seguridad de las empresas evalúan el riesgo de los proveedores, recurren a marcos estandarizados como Shared Assessments SIG Lite (v2024/2025), el Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CSA CAIQ v4) y los perfiles de proveedores de Whistic. Estas evaluaciones se centran en reglas de validación estrictas dentro de la gestión de amenazas y vulnerabilidades (TVM).

Los equipos de compras de las empresas rara vez revisan el código interno de su aplicación ni los detalles sensibles de reproducción de vulnerabilidades. Compartir exploits de prueba de concepto sin procesar introduce riesgos para la propiedad intelectual y peligros operativos. En su lugar, los compradores evalúan dos documentos de verificación externos bajo acuerdos de confidencialidad:

1. La Carta de Atestación (LoA) independiente: Una declaración firmada, en papel con membrete del proveedor de las pruebas, que confirma las fechas de la evaluación, el alcance definido de las pruebas, la metodología estandarizada y la postura de riesgo general.
2. El informe de resumen ejecutivo: Una visión general para la dirección, depurada de información sensible, que resume la cobertura de las pruebas, la distribución de vulnerabilidades por severidad y el estado de corrección, sin exponer payloads de exploits sin procesar.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           ENTERPRISE TPRM EVALUATION WORKFLOW                           │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   Enterprise Prospect                                     Startup / Vendor              │
│  ┌────────────────────┐   Sends Questionnaire (SIG / CAIQ) ┌─────────────────────────┐  │
│  │ Procurement & TPRM │ ─────────────────────────────────► │ Sales & Security Team   │  │
│  └─────────┬──────────┘                                    └────────────┬────────────┘  │
│            │                                                            │               │
│            ▼ Verifies Attached Evidence                                 ▼ Evidence      │
│  ┌───────────────────────────────────────────────────────────────────────────────────┐  │
│  │ 1. Independent Third-Party Letter of Attestation (LoA) (Signed, < 12 months)      │  │
│  │ 2. Scoping Document (Production Web, APIs, Mobile Apps, Cloud Boundaries)          │  │
│  │ 3. Remediation Verification (Zero unresolved Critical / High findings)             │  │
│  │ 4. Recognized Methodology (OWASP Top 10, OWASP WSTG, NIST SP 800-115, PTES)        │  │
│  └───────────────────────────────────────────────────────────────────────────────────┘  │
│            │                                                                            │
│            ├─► Raw Scanner Export (Nessus/ZAP) ──────────► REJECTED (Deal Blocked)      │
│            │                                                                            │
│            └─► AI Pentest Attestation + PoC Traces ──────► APPROVED (Deal Unblocked)    │
└─────────────────────────────────────────────────────────────────────────────────────────┘

Para superar el proceso de compras de la empresa, su paquete de pruebas de penetración debe cumplir cuatro criterios irrenunciables:

• Independencia estructural de terceros: Las autoevaluaciones, las revisiones internas de ingeniería y las salidas de herramientas sin procesar ejecutadas por sus propios desarrolladores no superan la inspección de inmediato. Los compradores exigen una evaluación externa y objetiva.
• Alcance completo y alineado: El alcance de las pruebas debe reflejar los límites de producción que almacenan datos de clientes. Si su arquitectura incluye paneles web, microservicios backend REST o GraphQL y aplicaciones móviles (iOS/Android), probar únicamente el dominio web de marketing genera excepciones de auditoría.
• Metodología de pruebas estandarizada: La evaluación debe citar marcos reconocidos del sector, como NIST SP 800-115, la OWASP Web Security Testing Guide (WSTG), el OWASP API Security Top 10 y el OWASP Mobile Application Security Verification Standard (MASVS).
• Corrección documentada y verificación mediante nueva prueba: Los compradores empresariales descalifican a los proveedores con vulnerabilidades abiertas de severidad crítica o alta. Si se identifican fallos durante las pruebas iniciales, su paquete debe incluir documentación verificada de la nueva prueba que demuestre el cierre satisfactorio.

¿Por qué los auditores de SOC 2 rechazan los escaneos de vulnerabilidades automatizados?

Los auditores de SOC 2 rechazan los escaneos de vulnerabilidades automatizados como sustituto de las pruebas de penetración porque los criterios de servicios de confianza (Trust Services Criteria) del AICPA separan la detección de vulnerabilidades (CC7.1) de la evaluación operativa de los controles (CC4.1). Aunque el escaneo automatizado satisface el requisito de identificar vulnerabilidades conocidas (CC7.1), los auditores y los equipos de seguridad de las empresas exigen evaluaciones independientes que comprueben activamente si los controles internos funcionan bajo la presión de un adversario (CC4.1), un estándar que las comprobaciones aisladas de un escáner no pueden satisfacer.

Los fundadores suelen preguntar si ejecutar un escáner de vulnerabilidades automatizado como Nessus, Qualys u OWASP ZAP cumple el requisito de pruebas de penetración para el cumplimiento de SOC 2. En la práctica, los auditores de SOC 2 distinguen el escaneo automatizado de vulnerabilidades de las pruebas de penetración: el escaneo identifica posibles fallos a partir de firmas conocidas, mientras que las pruebas de penetración exigen comprobar activamente si los controles pueden eludirse y demostrar la viabilidad del exploit.

La explicación está en el lenguaje exacto de los criterios de servicios de confianza (Trust Services Criteria) del American Institute of Certified Public Accountants (AICPA) en la sección 100 de TSP.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                       AICPA TRUST SERVICES CRITERIA & AUDIT MAPPING                     │
├──────────────────────────────────────────┬──────────────────────────────────────────────┤
│ CC7.1: Vulnerability Identification      │ CC4.1: Monitoring & Separate Evaluations     │
├──────────────────────────────────────────┼──────────────────────────────────────────────┤
│ • Goal: Detect vulnerabilities & patches │ • Goal: Evaluate if controls actually WORK   │
│ • Tooling: Vulnerability Scanners        │ • Tooling: Penetration Testing               │
│   (Nessus, Qualys, Trivy, Dependabot)    │   (Autonomous Agents + Human Validation)     │
│ • Mechanism: Version checks & signatures │ • Mechanism: Active Adversary Simulation     │
│ • Artifact: Scan summaries, patch logs   │ • Artifact: Proof of Concept (PoC), LoA      │
│ • Audit Role: Core Evidence for CC7.1    │ • Audit Role: Industry Benchmark for CC4.1   │
└──────────────────────────────────────────┴──────────────────────────────────────────────┘

La diferencia entre CC7.1 y CC4.1

Los criterios de servicios de confianza separan la gestión de vulnerabilidades de las pruebas operativas de los controles:

1. CC7.1 (operaciones del sistema: gestión de vulnerabilidades): Exige que una entidad implemente procedimientos de detección para identificar cambios de configuración y vulnerabilidades del sistema. Los escaneos de vulnerabilidades automatizados, las comprobaciones de dependencias y los escaneos de imágenes de contenedores satisfacen CC7.1 al demostrar que su equipo escanea en busca de fallos de software conocidos.
2. CC4.1 (principio 16 de COSO: evaluaciones continuas e independientes): Exige evaluaciones independientes para determinar si los componentes de control interno están presentes y funcionan bajo presión activa. Revisar una política de seguridad confirma que existe una regla sobre el papel; atacar la aplicación en ejecución confirma que el control resiste realmente el acceso no autorizado. Aunque los criterios del AICPA no exigen expresamente las pruebas de penetración, los auditores y los equipos de TPRM de las empresas consideran las pruebas de penetración independientes la actividad de control estándar para respaldar las evaluaciones de CC4.1.

Cuatro fallos estructurales de los escaneos de vulnerabilidades sin procesar

Los escaneos de vulnerabilidades sin procesar no alcanzan el umbral de CC4.1 por cuatro motivos distintos:

• Ninguna prueba de explotación: Los escáneres comparan banners de software y patrones de expresiones regulares para emitir hipótesis especulativas (como «Potential Apache flaw»). No ejecutan un ataque para confirmar si el endpoint es accesible, ejecutable o está protegido por firewalls ascendentes.
• Incapacidad para probar fallos de lógica de negocio: Los escáneres envían solicitudes HTTP aisladas. No pueden evaluar flujos de autorización de varios pasos, como la autorización defectuosa a nivel de objeto (BOLA/IDOR), las fugas de datos entre inquilinos o la escalada de privilegios entre roles autenticados.
• Altas tasas de falsos positivos: Los escáneres automatizados producen con regularidad entre un 20% y un 50% de ruido de falsos positivos. Los auditores CPA se niegan a clasificar alertas sin verificar, lo que obliga al proveedor a demostrar su validez manualmente.
• Falta de contexto adversarial: Los auditores exigen evidencias de que un atacante no puede encadenar varios problemas de baja severidad en una ruta crítica de exfiltración de datos. Los escáneres evalúan los parámetros de forma aislada y no pueden encadenar los pasos de un ataque.

El papel de la responsabilidad nominal en la aceptación de la auditoría

Los auditores no juzgan las evaluaciones por si se utilizaron herramientas de IA durante su ejecución. Evalúan la credibilidad de las evidencias, la transparencia de la metodología y la responsabilidad humana nominal. Un informe generado exclusivamente por un script automatizado sin verificar y sin supervisión humana se interpreta como una autoevaluación sin validar.

Para cumplir los estándares de auditoría, un paquete de evaluación requiere: * Prueba verificable de solicitud/respuesta que muestre un impacto real. * Una metodología documentada e inspeccionable, alineada con estándares reconocidos. * Una revisión humana cualificada y nominal que valide la exactitud de los hallazgos y firme la atestación. * Límites de alcance claros, mapeados directamente a la descripción del sistema de SOC 2.

Evaluación de las opciones: consultoras tradicionales frente a escáneres frente a Ostorlab AI Pentest

Las startups que evalúan opciones de pruebas de penetración se enfrentan a tres modelos de entrega distintos. Comprender sus diferencias estructurales ayuda a los equipos a elegir el enfoque adecuado en términos de velocidad de ventas y rigor de cumplimiento.

Cómo ofrece Ostorlab un rigor de nivel de auditoría sin los retrasos de la consultoría

Ostorlab combina la tecnología autónoma de Agentic Deep Scan con la validación de exploits. En lugar de generar alertas hipotéticas, los agentes autónomos exploran el estado de la aplicación, formulan hipótesis de ataque contextuales y ejecutan exploits verificados, y cada hallazgo confirmado se entrega con un exploit funcional.

Figura 1: Resumen del informe de evaluación de Ostorlab Agentic Deep Scan. El panel muestra la calificación de riesgo global, el alcance de la arquitectura objetivo, la duración del escaneo y el desglose categorizado de vulnerabilidades, listo para la inspección del auditor.

1. Prueba determinista de explotabilidad (PoC)

Los auditores y los revisores de las empresas exigen evidencias verificables. Los hallazgos de Ostorlab no se basan en puntuaciones de confianza subjetivas. Cada hallazgo notificado aporta una prueba determinista adaptada al activo objetivo (pares completos de solicitud y respuesta HTTP con comandos curl para web y API, desencadenantes de IPC y registros de ejecución para las aplicaciones móviles, y rutas de ejecución verificadas para los problemas a nivel de código), junto con un análisis preciso de la causa raíz.

Figura 2: Vista detallada de un hallazgo en la plataforma Ostorlab. El informe establece la severidad, la confirmación de la causa raíz, las rutas de código afectadas y unos pasos de reproducción claros para que los desarrolladores corrijan el defecto subyacente sin ambigüedades.

Considere este hallazgo depurado de autorización defectuosa a nivel de objeto (BOLA) descubierto durante una evaluación de API autenticada:

POST /api/v2/workspaces/ws_89234/billing/invoices HTTP/1.1
Host: target-api.internal-saas.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "target_tenant_id": "tenant_enterprise_7710",
  "request_export": true
}

La respuesta del servidor confirma la exfiltración de datos de un inquilino a través de los límites de la organización:

HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 11 Sep 2026 14:22:04 GMT

{
  "status": "success",
  "tenant_id": "tenant_enterprise_7710",
  "invoices": [
    {
      "invoice_id": "inv_99812",
      "amount_usd": 124500.00,
      "billing_contact": "finance@fortune500-client.com",
      "payment_method": "ACH_****8812"
    }
  ]
}

Figura 3: Prueba de explotación en tiempo de ejecución generada por el agente. La respuesta descifrada demuestra una exposición real de datos y ofrece a los auditores una prueba indiscutible del compromiso, en lugar de una heurística teórica.

El hallazgo va acompañado de una comprobación de referencia diferencial que demuestra que los endpoints no vulnerables aplican comprobaciones estrictas de inquilino. Los desarrolladores reciben un comando de reproducción accionable, mientras que los auditores reciben una prueba indiscutible de la explotación.

2. Pila multiactivo unificada: web, API y móvil

Las arquitecturas SaaS modernas van más allá de las aplicaciones web tradicionales. Los microservicios backend, las pasarelas GraphQL y los clientes móviles nativos (iOS y Android) interactúan directamente con los datos de los clientes empresariales.

Figura 4: Metodología de pruebas inspeccionable de un Ostorlab Agentic Deep Scan. Los auditores pueden inspeccionar el agente de planificación nominal, los objetivos explícitos y las tareas de ejecución por fases, lo que demuestra el cumplimiento de los estándares formales de pruebas de penetración.

Los escáneres web de propósito único no pueden descompilar binarios móviles ni eludir la fijación de certificados. Ostorlab ofrece pruebas multiactivo unificadas: * Escaneo profundo de web y API: Exploración autónoma del estado, ingesta de colecciones OpenAPI y Postman, y pruebas dinámicas de los controles de autorización. * Instrumentación dinámica móvil: Pruebas automatizadas de aplicaciones Android (APK) e iOS (IPA) mediante el framework de pruebas dinámicas Monkey, la instrumentación en tiempo de ejecución y la detección de riesgos en el almacenamiento local. * Análisis de pivotaje entre activos: Descubrimiento de secretos móviles incrustados en el código y encadenamiento de estos para extraer recursos no autorizados de la API del backend.

3. Nueva prueba de la corrección con un clic mediante Risk Reruns

En una prueba de penetración tradicional, corregir una vulnerabilidad es solo la mitad de la batalla. Verificar la corrección requiere contactar con la consultora, esperar a que haya un auditor disponible y, a menudo, pagar una tarifa adicional por la nueva prueba.

Ostorlab elimina esta fricción operativa mediante Risk Reruns y Single Vulnerability Assessment (SVA): 1. Los desarrolladores inspeccionan el payload exacto de reproducción y suben una corrección de código a staging o producción. 2. Con un clic, el equipo de ingeniería lanza un Risk Rerun dirigido directamente contra el endpoint afectado. 3. El agente autónomo vuelve a ejecutar exactamente la misma cadena de explotación con credenciales de sesión nuevas. 4. Si el ataque se bloquea con éxito, la plataforma actualiza el estado del hallazgo a «Remediated» y registra una entrada de verificación con marca de tiempo en el registro de auditoría.

Figura 5: Interfaz de Risk Reruns con un clic. Los desarrolladores vuelven a probar al instante los vectores corregidos y generan registros de verificación con marca de tiempo criptográfica que los auditores aceptan para el cierre limpio de la corrección.

4. Validación y atestación con responsables identificados

Cada paquete de AI Pentest incluye un exploit funcional por cada hallazgo que confirman los agentes y una ventana de nueva prueba. La validación humana no forma parte de todos los paquetes; consulte la comparación de planes para ver dónde se incluye o dónde está disponible como complemento. El paquete final del informe incluye: * Un resumen ejecutivo con métricas de riesgo de alto nivel para la dirección y los compradores empresariales bajo NDA. * Un mapeo completo del alcance técnico y de la metodología (NIST SP 800-115, OWASP WSTG). * Un registro de correcciones verificado que demuestra que no hay vulnerabilidades críticas ni altas abiertas. * Una Carta de Atestación formal y firmada, aceptada por las principales plataformas de cumplimiento (Vanta, Drata, Secureframe).

Cómo obtienen las startups un informe de pentest listo para auditoría en aproximadamente una semana

Las startups pueden pasar de la definición inicial del alcance a una Carta de Atestación firmada y lista para auditoría en un plazo estimado de 5 a 7 días para una evaluación Core (de 10 a 14 días para Advanced y de 15 a 20 días para Elite) siguiendo un flujo de trabajo de pentest de 4 fases. Las fases que se indican a continuación muestran el orden del trabajo, no duraciones garantizadas:

Actualizado el 1 de octubre de 2026: las afirmaciones sobre el plazo de entrega y la validación humana de este artículo se corrigieron para que coincidan con la página actual de planes. Actualizado el 5 de octubre de 2026: se eliminó la insignia de seguridad, que no se ofrece.

1. Fase 1: Recepción del alcance y credenciales iniciales: Defina los límites de los datos de clientes documentados en la descripción del sistema de SOC 2. Incorpore las URL web, los esquemas de API y los binarios móviles, y proporcione dos credenciales de usuario distintas para probar los controles de autorización multiinquilino.
2. Fase 2: Agentic Deep Scan autónomo: Los agentes autónomos mapean el estado de la aplicación, descubren endpoints no indexados y ejecutan cadenas de explotación en los flujos de autenticación, autorización y lógica.
3. Fase 3: Corrección dirigida por los desarrolladores: Los desarrolladores revisan los hallazgos críticos y altos priorizados. Dado que cada hallazgo incluye evidencias de reproducción específicas del activo (trazas HTTP y comandos curl para web y API, desencadenantes de IPC y registros de ejecución para las aplicaciones móviles, y rutas de ejecución verificadas para los hallazgos a nivel de código), los ingenieros corrigen la causa raíz sin ambigüedades de triaje.
4. Fase 4: Nueva prueba con 1 clic y exportación de la LoA: El equipo de ingeniería lanza Risk Reruns sobre los vectores corregidos dentro de la ventana de nueva prueba incluida. Se registran los cierres verificados y se entregan la Carta de Atestación y el paquete de auditoría para desbloquear el proceso de compras.

Preguntas frecuentes sobre pentesting para SOC 2

¿Aceptará un auditor de SOC 2 un informe de pruebas de penetración dirigido por IA?

Sí. Los criterios de servicios de confianza del AICPA (sección 100 de TSP) especifican el rigor de las pruebas y los estándares de evidencia, no la identidad biológica de quien las realiza. Las principales firmas de auditoría CPA aceptan las pruebas de penetración agénticas siempre que la evaluación siga metodologías establecidas (como NIST SP 800-115 y OWASP WSTG), incluya pruebas deterministas de explotación, ofrezca un alcance de pruebas definido e incluya una Carta de Atestación independiente, revisada por una persona, que confirme la corrección.

¿En qué se diferencia un pentest agéntico bajo demanda de un escaneo de vulnerabilidades automatizado?

Los escáneres de vulnerabilidades automatizados se basan en la coincidencia estática de patrones, en comprobaciones aisladas de payloads y en la inspección de banners de versión, y producen altas tasas de falsos positivos sin confirmar la explotabilidad. Una prueba de penetración agéntica interactúa activamente con los flujos de trabajo de la aplicación, genera exploits dinámicos, encadena varias debilidades, valida los límites de autorización entre cuentas distintas y aporta evidencias verificadas de prueba de concepto.

¿El área de compras de una empresa exige un informe técnico completo o solo una carta de atestación?

Los compradores empresariales exigen habitualmente una Carta de Atestación (LoA) firmada y un resumen ejecutivo depurado bajo un acuerdo de confidencialidad. Compartir informes técnicos de vulnerabilidades sin procesar expone endpoints sensibles de la aplicación e instrucciones de explotación, algo que los equipos de riesgos de las empresas no necesitan. La Carta de Atestación confirma la independencia de terceros, la integridad del alcance y la ausencia de vulnerabilidades altas o críticas sin mitigar.

¿Cómo se compara el precio de Ostorlab con las pruebas de penetración tradicionales?

Las consultoras de pruebas de penetración tradicionales cotizan entre $15,000 y $40,000 por evaluaciones puntuales con semanas de retraso. Ostorlab ofrece precios transparentes por niveles, con paquetes Core AI Pentest acotados desde $499 bajo demanda (que escalan de forma transparente con el alcance y la complejidad de la aplicación), con soporte multiactivo y una ventana de nueva prueba incluidos. La validación humana depende del plan; consulte la comparación de planes.

¿Pueden las pruebas de penetración agénticas respaldar los periodos de observación de SOC 2 Type 2?

Sí. Las auditorías de SOC 2 Type 2 exigen pruebas de la eficacia continua de los controles durante una ventana de tres a doce meses. Los pentests anuales tradicionales dejan meses de cambios de código sin evidencias. Las pruebas agénticas bajo demanda permiten a los equipos de seguridad ejecutar evaluaciones recurrentes en las versiones principales y establecer un rastro de evidencias ininterrumpido durante toda la ventana de auditoría.

Estándares y referencias principales

• American Institute of Certified Public Accountants (AICPA). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100).
• National Institute of Standards and Technology (NIST). Technical Guide to Information Security Testing and Assessment (NIST SP 800-115).
• Open Web Application Security Project (OWASP). Web Security Testing Guide (WSTG v4.2).
• Open Web Application Security Project (OWASP). API Security Top 10.
• Shared Assessments. Standardized Information Gathering (SIG Lite) Questionnaire.
• Cloud Security Alliance (CSA). Consensus Assessments Initiative Questionnaire (CAIQ v4).