TRA-001 v2.0 — Master Targeted Risk Analyses

Campo	Valor
ID	TRA-001
Versión	2.0 (supersede v1.0 emitida 2026-06-16)
Fecha de emisión v2.0	2026-06-16
Próxima revisión obligatoria	2027-06-16 (anual, PCI 12.3.1.5)
Propietario	CISO + CTO (Gabriel Ureña — acting both)
Aprobado por	Executive Management (Inversionista Board representation) + CTO
PCI DSS	Req 12.3.1, 12.3.1.1 a 12.3.1.5 (Targeted Risk Analysis methodology)
Aplica a	Toda decisión de frecuencia flexible PCI DSS + customized approach
Status	ACTIVE — covers all PCI flexibility requirements + customized approaches

---

Historial de revisiones

Versión	Fecha	Cambios
1.0	2026-06-16	Emisión inicial — cubría solo PCI 7.2.5.1 (service account review frequency)
2.0	2026-06-16	Expansión a Master Document — cubre los 9 requisitos PCI con flexibilidad + customized approach

---

1. Methodology + Policy (PCI 12.3.1)

1.1 Propósito

Definir la metodología única que Fintrixs SAS usa para ejecutar Targeted Risk Analyses (TRA) según PCI DSS v4.0 Req 12.3.1. Cada decisión de frecuencia "flexible" que PCI permite + cada uso de "Customized Approach" se justifica con un TRA siguiendo este documento.

1.2 Alcance

Este documento cubre:

Categoría	Items en alcance
Flexibility requirements	9 requisitos PCI DSS v4.0 que permiten frecuencia definida por TRA (§2)
Customized approaches	Todos los requisitos donde Fintrixs adopta customized approach (§3) excepto los 7 ineligibles
Ineligibles para customized	Req 3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.2, 3.5.1.2, 11.3.2 (excluidos)

1.3 Los 5 elementos del TRA (PCI 12.3.1)

Cada análisis individual en este documento sigue exactamente la estructura PCI Req 12.3.1:

Elemento	Descripción
§E1 Activo	Qué activo protegemos con este control
§E2 Factores de probabilidad e impacto	Qué hace al activo más/menos probable de ser comprometido + impacto
§E3 Factores de frecuencia	Qué consideraciones determinan la frecuencia
§E4 Frecuencia/control resultante	La decisión final (frecuencia + alternatives considered)
§E5 Aprobación de la dirección	Sign-off de Executive Management

1.4 Workflow de aprobación

Step 1: CISO/CTO drafta TRA per control en plantilla §1.6
Step 2: Risk scoring por factor (1-5 scale per dimension)
Step 3: Frecuencia/control resultante calculado
Step 4: Alternatives considered documentadas
Step 5: Sign-off del Executive Management (Board)
Step 6: Archive con SHA-256 + storage path
Step 7: Re-evaluation anual + ad-hoc triggers

1.5 Revisión anual obligatoria (PCI 12.3.1.5)

Este Master Document se revisa completamente cada año. Próxima revisión: 2027-06-16.

Revisión incluye:

• Validar que cada TRA per-control sigue siendo apropiado
• Validar que la metodología sigue cubriendo todos los flexibility requirements
• Identificar new flexibility/customized approaches introducidos por PCI updates
• Re-aprobación por Executive Management

1.6 Triggers de re-evaluation inmediato (ad-hoc)

Trigger	Acción
Nuevo flexibility requirement en PCI v4.x update	Add nuevo §2.X TRA
Significant change en arquitectura	Re-evaluar TRAs afectados
Incident severity Critical	Re-evaluar TRA del control involucrado
Auditor externo recomienda cambio	Evaluar + ajustar
Cambio de TPSP crítico	Re-evaluar §2.X que dependa

1.7 Scoring methodology

Para cada factor en §E2 y §E3, asignamos score 1-5:

Score	Probability	Impact	Frequency factor
1	Very low (≤5% per year)	Negligible	Annual+ acceptable
2	Low (5-15%)	Minor (recoverable in hours)	Semestral acceptable
3	Medium (15-40%)	Moderate (recoverable in days)	Trimestral required
4	High (40-70%)	Major (data loss + regulatory impact)	Monthly required
5	Very high (>70%)	Severe (CHD exposure + reputational damage)	Continuous/daily required

Frecuencia resultante = max(impact * 0.6 + probability * 0.4, frequency_factor).

---

2. Per-Flexibility Requirement TRAs

2.1 PCI Req 5.2.3.1 — Anti-malware periodic evaluations

Context: PCI 5.2.3 exige que los antimalware solutions sean actively running. 5.2.3.1 permite frecuencia evaluation flexible para systems considered "not commonly affected" by malware.

§E1 Activo

Sistemas no comúnmente afectados por malware en Fintrixs:

• DigitalOcean Kubernetes nodes (Debian GNU/Linux 13 — server, no email/browsing)
• DBaaS (managed by DO — no malware vector)
• Wazuh nodes (dedicated security infra)
• Container images (immutable, signed)

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — server-class workload no end-user	2 / Low	Sin email/browsing, attack surface minimal
Probability — container immutability	1 / Very low	Containers re-deployed daily; ephemeral
Probability — privileged container access	2 / Low	Falco monitoring runtime + readOnlyRootFS
Impact — kernel-level compromise	5 / Severe	Container escape → cluster compromise
Impact — application-level compromise	3 / Moderate	Limited by RBAC + namespace isolation

§E3 Factores de frecuencia

Pregunta	Respuesta
¿Hay vectores email/browsing?	NO — server-only
¿Containers immutable?	SÍ — re-deploy daily
¿Falco IDS runtime activo?	SÍ — covers gaps (Q80)
¿Wazuh syscheck FIM?	SÍ — file integrity continuous (Q81)
¿Auth scanning Wazuh vuln-detection?	SÍ — 60min feed update (Q74)

§E4 Frecuencia resultante

Decisión: Evaluation mensual de la determinación "not commonly affected" + scanning continuo via Falco + Wazuh syscheck en lugar de signature-based antimalware tradicional.

Justificación: Sin signature-based antimalware en server-class workloads + runtime IDS (Falco) provee detection equivalente o superior, mensual evaluation verifica que el assessment sigue válido.

Alternatives considered:

• ClamAV instalado en cada nodo (rejected — high CPU + low signal en server workload)
• Anti-malware vendor commercial (rejected — costoso, redundant con Falco)
• Anti-malware evaluado cada 6 meses (rejected — too long given threat landscape evolution)

§E5 Aprobación

Approved by CTO + Executive Management 2026-06-16.

---

2.2 PCI Req 5.3.2.1 — Anti-malware periodic scans

Context: PCI 5.3.2 exige scans periodic. 5.3.2.1 permite frecuencia definida por TRA cuando "no periodic scan" se aplica (continuous active scans en su lugar).

§E1 Activo

Continuous active scanning vs periodic scanning decision.

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability of malware introduction via continuous deploy	3 / Medium	CI/CD pipeline can introduce supply chain attacks
Probability — image signing + provenance	1 / Very low	Signed images required by admission controller
Impact — undetected malware in production	5 / Severe	CHD exposure possible

§E3 Factores de frecuencia

• Falco runtime detection: continuous (eBPF kernel)
• Wazuh syscheck FIM: realtime (28 paths) + 12h scheduled
• Container image scanning: per-PR via GitHub Actions (signed Trivy reports)
• Wazuh vulnerability detection: 60min feed update

§E4 Frecuencia resultante

Decisión: Continuous active scanning (Falco runtime + Wazuh syscheck realtime) en lugar de periodic scans. Equivalent (or superior) detection capability per PCI 5.3.2.1.

Justificación: Continuous beats periodic on detection latency. PCI 5.3.2.1 permite "continuously active... in place of periodic scans".

Alternatives:

• Quincenal full system scan (rejected — duplicates Falco continuous)
• Mensual signature DB update + scan (rejected — Falco already does this via rule updates)

§E5 Aprobación

Approved 2026-06-16.

---

2.3 PCI Req 7.2.5.1 — Service account review frequency

Nota: Esta sección reemplaza el TRA-001 v1.0 anterior, ahora integrado como §2.3 del master.

§E1 Activo

29 service accounts en 7 categorías:

Cat	Descripción	Ejemplos	Count
A	DB primary admin	doadmin (PG prod/staging)	2
B	K8s cluster-admin	admin-prod, deployer-prod	2
C	App production SA	fintrix_app + microservice JWTs	12
D	Read-only SA	fintrix_readonly, viewer-prod	2
E	Infra automation	DO PAT + GitHub Apps	3
F	Vendor SA	controlcase_auditor, kibanaserver	4
G	Compensating control	Kong admin key, GoPhish	4

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
F1 — SA credentials no rotan auto	4 / High	Static credentials persist hasta humano las rote
F2 — SA son no-MFA por naturaleza	3 / Medium	Password/token robado da acceso inmediato
F3 — Volumen de SAs	3 / Medium	~29 cuentas + drift risk
F4 — Privilegios concentrados	4 / High	doadmin + admin-prod single-point compromise
F5 — Vendor SAs con TTL olvidados	3 / Medium	controlcase_auditor temp risk
I1 — Acceso a PANs	5 / Severe	fintrix_app puede tocar card-vault
I2 — DBaaS DROP TABLE	5 / Severe	doadmin destrucción
I3 — Pivot via K8s admin	4 / High	cluster-wide write

§E3 Factores de frecuencia

• Cambio de privilegios velocidad: días-semanas (CI/CD deploys)
• Descubrimiento SAs nuevos: continuous (cada microservicio)
• Controles automáticos: Q48 monthly inactive audit + Q45 listing snapshot
• Single humano gestiona ciclo de vida (single-person SPOF)

§E4 Frecuencia resultante

Decisión: TRIMESTRAL para todas las categorías (Q1/Q2/Q3/Q4).

Justificación: Trimestral aligns con ciclos de release + reduce ventana de drift. CDE multi-tenant amerita el frecuencia más estricta de las opciones aceptables (anual / semestral / trimestral).

Alternatives:

• Anual (rejected — drift de 12 meses inaceptable)
• Semestral (rejected — alineado con Q1031 humanos, pero SAs son más volátiles)

§E5 Aprobación

Approved 2026-06-16. Primer ciclo Q2 2026 documentado en Q1032.

---

2.4 PCI Req 8.6.3 — Application/system account password change frequency

§E1 Activo

Passwords/tokens de service accounts (cuando MFA no disponible por design).

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — credential leak via logs	2 / Low	Logging mask sensitive (Q67)
Probability — credential leak via git commit	2 / Low	Pre-commit hooks + secret scanning
Probability — credential leak via insider	3 / Medium	Single-person org, low insider risk
Probability — credential leak via vendor	3 / Medium	Multiple vendors
Impact — token gives full DB access	5 / Severe	doadmin → full DB
Impact — token gives K8s admin	5 / Severe	cluster compromise

§E3 Factores de frecuencia

• Manual rotation effort: 1-2 hours per SA
• Number of SAs to rotate: 29
• Annual cost: 29 SAs × 4 (quarterly) × 1.5h = 174 hours = ~5 weeks of CTO work
• Risk of rotation-induced outage: medium (config drift)
• Automated rotation feasibility: high for Kong + GoPhish, low for vendor accounts

§E4 Frecuencia resultante

Decisión: Trimestral para Cat A/B/C/G + on-event para Cat F (vendor accounts) + annual para Cat D/E (read-only + infra automation).

Justificación: Risk-graded approach. High-impact (DB+K8s admin) rotan trimestralmente. Lower-risk (read-only) anual. Vendor accounts rotan al cambio de vendor.

Alternatives:

• Universal 90-day rotation (rejected — operational cost high)
• 180-day rotation (rejected — too long for high-impact SAs)

§E5 Aprobación

Approved 2026-06-16.

---

2.5 PCI Req 9.5.1.2.1 — POI device inspection frequency

§E1 Activo

Fintrixs SAS no opera POI devices. Esta sección documenta el TRA para los merchants que SÍ los operan.

§E2 Probabilidad + Impacto (en merchants que operan POIs)

Factor	Score	Razonamiento
Probability — POI tampering high-traffic mall	4 / High	Many customers + public access
Probability — POI tampering low-traffic office	2 / Low	Limited public access
Probability — POI substitution (full swap)	2 / Low	Visible + serial check
Impact — skimmer captures PANs	5 / Severe	Mass CHD compromise

§E3 Factores de frecuencia

Frecuencia	Pros	Cons
Diaria	Catches recent tampering quickly	High labor cost
Semanal	Reasonable cost	Tampering can persist 6 days
48h	Hybrid	Suitable for kiosks

§E4 Frecuencia resultante

Decisión documentada en GUI-001 §3.1:

Risk del entorno	Frecuencia
Mall / Retail alto tráfico	DIARIA (cada turno)
Oficina / Restaurante	SEMANAL
Kiosk desatendido	CADA 48 HORAS

Justificación: Risk-graded by environment. High-traffic = highest frequency. Low-traffic = balance cost vs risk.

§E5 Aprobación

Aplicable solo a merchants. Fintrixs no implementa (POL-016 declarativa).

---

2.6 PCI Req 10.4.2.1 — Log review frequency for non-critical systems

§E1 Activo

Logs de sistemas non-critical (donde "non-critical" se define por TRA):

Sistema	Critical?	Justificación
OS auth.log no exposed	No	No internet-facing
App info logs	No	Low signal
DBaaS slow queries	No	Performance, no security
Wazuh syscheck history	No	FIM realtime is the actual signal

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — useful signal in non-critical logs	2 / Low	Most events normal operations
Probability — missing critical event delayed	3 / Medium	If review delayed > weeks
Impact — missed security event	3 / Moderate	Critical events already in critical-tier review

§E3 Factores de frecuencia

• Critical events ya reviewed daily (Q71 SOP-007 §3)
• Wazuh + Falco surface critical events realtime
• Non-critical = primarily operational + low-signal
• Single-person org capacity: limited

§E4 Frecuencia resultante

Decisión (documentada en SOP-007 §4):

Sistema	Frecuencia
DBaaS slow queries	Semanal
Wazuh syscheck history	Semanal
OS auth.log + auditd	Mensual
Application info logs	On-demand

Justificación: Semanal/mensual balance ops capacity vs risk. Critical-tier ya covered daily.

Alternatives:

• Daily review all (rejected — single-person bandwidth)
• Quarterly review (rejected — too long for system anomalies)

§E5 Aprobación

Approved 2026-06-16.

---

2.7 PCI Req 11.3.1.1 — IVA frequency for low-risk systems

§E1 Activo

Internal vulnerability assessment frequency. "Low-risk" se define por TRA.

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — new CVEs daily	5 / Very high	NVD ~50 CVEs/day
Probability — exploit weaponization	3 / Medium	Days-weeks for high-profile
Impact — privilege escalation via CVE	4 / High	Lateral movement
Impact — info disclosure CVE	3 / Moderate	Limited blast radius

§E3 Factores de frecuencia

• Wazuh vuln-detection continuous (60min feed)
• ASV quarterly external (Q75)
• ENPT/APT annual (Q77)
• Dependabot daily

§E4 Frecuencia resultante

Decisión: Continuous (Wazuh vuln-detection 60min feed updates + 24h cycle) en lugar de point-in-time quarterly scans.

Per-sistema:

Sistema	Frequency	Mechanism
DOKS nodes	Continuous	Wazuh DaemonSet + Trivy + Dependabot
Droplets	Continuous	Wazuh agent
DBaaS	Vendor-managed	DO does scans
VAPT (powered off)	N/A	Out of scope (POL-016)
CDD (powered off)	N/A	Out of scope

Justificación: Continuous beats quarterly. Critical CVEs ne quarterly window allow exploit.

Alternatives:

• Quarterly only (rejected — exploit window too long)
• Monthly (rejected — Wazuh continuous already covers)

§E5 Aprobación

Approved 2026-06-16. Coverage 12/14 systems with continuous + 2 EXEMPT documented (Q74).

---

2.8 PCI Req 11.6.1 — Payment page change-and-tamper detection frequency

§E1 Activo

Payment page /checkout/payment recibida por browser del consumidor.

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — supply chain attack on JS deps	3 / Medium	npm ecosystem risk
Probability — direct page tampering	2 / Low	Need K8s compromise first
Probability — CDN poisoning	2 / Low	DO Spaces signed URLs
Impact — skimmer captures PANs at point of entry	5 / Severe	Direct CHD compromise

§E3 Factores de frecuencia

• CSP report-uri: realtime (in-browser violation reports)
• SRI hash check: per-request (in-browser)
• Synthetic monitor: scheduled
• Wazuh syscheck on build: realtime (FIM inotify)

§E4 Frecuencia resultante

Decisión: 4-layer approach con frecuencia variable:

Layer	Frequency	Implementation
CSP browser-side	Realtime	Per-request browser enforcement + report-uri
SRI browser-side	Realtime	Per-request browser enforcement
Synthetic monitor	24h scheduled	GitHub Actions cron
Wazuh syscheck build artifact	Realtime	inotify

Justificación: Defense-in-depth. Realtime is best detection. Synthetic 24h is independent verification (browser-side can be evaded by sophisticated attacker; synthetic is server-side baseline).

Alternatives:

• Synthetic monitor every 1 hour (rejected — false positive rate during deploys)
• Synthetic monitor weekly (rejected — too long, skimmer can run for 6 days)

§E5 Aprobación

Approved 2026-06-16. Implementation documented in Q1037.

---

2.9 PCI Req 12.10.4.1 — Incident response training frequency

§E1 Activo

Training periodicity for incident response team.

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — incident in next 12 months	3 / Medium	Multi-tenant platform + threat landscape
Probability — IR team unfamiliarity due to no training	3 / Medium	Skills decay
Impact — slow IR response	4 / High	Extended exposure window
Impact — wrong actions during IR	5 / Severe	Forensic evidence destroyed

§E3 Factores de frecuencia

• IR team size: 1 (CTO) — single-person org
• Recency bias: training too long ago = skills decay
• Training cost: 4-8 hours per cycle

§E4 Frecuencia resultante

Decisión: Semestral (cada 6 meses) IR training + tabletop exercise.

Mes	Activity
Junio (H1)	IR team training + tabletop scenario
Diciembre (H2)	IR team refresh + new tabletop scenario

Justificación: Semestral mantiene skills frescos sin sobrecargar capacity. Single-person org → CTO se entrena consigo mismo + tabletops desarrollan muscle memory.

Alternatives:

• Anual (rejected — skills decay too much in 12 months)
• Trimestral (rejected — capacity overload single-person)

§E5 Aprobación

Approved 2026-06-16. Próximo training: 2026-06-30 (H1 cycle).

---

3. Customized Approach Analyses

PCI DSS v4.0 permite Customized Approach para cumplir requirements de forma alternativa (cuando el defined approach no encaja). Los siguientes 7 requisitos son ineligibles para customized approach y se excluyen:

Req ineligible	Reason
3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3	PAN-specific storage requirements
3.3.2	Sensitive auth data after auth
3.5.1.2	Cryptographic key management
11.3.2	ASV scans (must use approved scanning vendor)

3.1 Customized approaches en uso en Fintrixs

Fintrixs SAS adopta Defined Approach para la mayoría de requirements. Customized approach se usa solo donde el defined approach no encaja con el modelo cloud-native single-tenant:

Req	Customized?	Razón
8.3.6 (password complexity)	CUSTOMIZED	PBKDF2-HMAC-SHA256 210k iter vs strict 12-char (§3.2.1)
8.3.11 (MFA bypass)	DEFINED	Standard implementation
11.4.x (pentest)	DEFINED	ControlCase standard methodology
11.5.x (IDS/IPS)	CUSTOMIZED	3-layer Falco+Wazuh+Coraza vs traditional signature IDS (§3.2.2)
12.5.2.1 (SP scope review)	DEFINED	SOP-008 standard cycle

3.2 Per-approach analysis

3.2.1 — Req 8.3.6 Password complexity (CUSTOMIZED)

Defined approach exige: 12+ chars, complejidad uppercase+lowercase+number+special.

Customized approach Fintrixs: PBKDF2-HMAC-SHA256 con 210,000 iteraciones (per OWASP 2023 guidance) + minimum 14 chars + breach password screening (HIBP API).

§E1 Activo: passwords protegen authentication

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — 12-char password cracked offline	5 / Very high	RTX 4090 cracks 12 char in ~3 hours
Probability — 14-char + 210k iter	1 / Very low	~10 years on same hardware
Impact — credential reuse compromise	5 / Severe	Direct CHD vault access

§E3 Factores de frecuencia

N/A (no frecuencia involved — design choice).

§E4 Customized control resultante

Decisión: 14+ chars + PBKDF2-HMAC-SHA256 210k iter + HIBP screening + bcrypt-derived comparison.

Justificación: Cumple intent de Req 8.3.6 (protect against brute force) con higher security guarantee. Per PCI Customized Approach Objective:

"Protect user authentication factors against brute-force attacks."

Verificación:

• Length: 14 chars verified by regex
• Hash: PBKDF2-HMAC-SHA256 210k iter (Q51 documented)
• Breach DB: HIBP API check on creation/change (Q53 + Q56)
• Audit: AUTH_PASSWORD_CHANGED event (Q67)

§E5 Aprobación

Approved 2026-06-16. Customized Approach Brief filed.

---

3.2.2 — Req 11.5.x IDS/IPS (CUSTOMIZED)

Defined approach exige: Network-based IDS/IPS at perimeter.

Customized approach Fintrixs: 3-layer detection combinando:

Layer	Tool	Coverage
Runtime IDS (kernel-level)	Falco (eBPF)	Container syscalls + lateral movement
Signature-based + correlation	Wazuh v4.9.2	Network + file + log events
HTTP L7 IDS+IPS	Coraza WAF v3 + OWASP CRS 4	HTTP attacks

§E1 Activo: CDE network + applications

§E2 Probabilidad + Impacto

Factor	Score	Razonamiento
Probability — traditional IDS misses container attacks	5 / Very high	Network-based blind to in-container exploits
Probability — eBPF Falco misses pure HTTP attacks	4 / High	No HTTP semantic understanding
Probability — WAF misses lateral movement	5 / Very high	WAF is HTTP-only
Impact — undetected lateral movement	5 / Severe	Full cluster compromise
Impact — undetected HTTP injection	5 / Severe	CHD exposure via app vulnerability

§E3 Factores de frecuencia

• All 3 layers operate continuously (continuous monitoring)
• Cada layer cubre ángulo diferente

§E4 Customized control resultante

Decisión: Implementar las 3 layers en paralelo:

• Falco DaemonSet (6 agents)
• Wazuh stack (manager + indexer + 4 agents)
• Coraza WAF integrated into Kong

Justificación: Defense in depth. Cada layer cubre ángulo que las otras 2 no pueden:

• Falco: kernel-level (covers container escape, syscall abuse)
• Wazuh: signature-based (covers known threats)
• Coraza: HTTP L7 (covers OWASP Top 10 + injection)

PCI Customized Approach Objective:

"Detect and prevent intrusions at the network perimeter and critical points within the network."

Nuestros 3 layers superan esta intent porque cubren container-level (no posible en traditional IDS).

§E5 Aprobación

Approved 2026-06-16. Customized Approach Brief filed. Q80 evidence.

---

4. Annual Review Log

Cycle	Review date	Reviewer	Findings	Re-approval date
2026 v1.0 → v2.0	2026-06-16	CTO + Executive Mgmt	Expansion to master + 9 flexibility + 2 customized	2026-06-16
2027 (mandatory)	2027-06-16	CTO + Executive Mgmt + QSA (años pares)	TBD	TBD

4.1 Significant changes que dispararon re-evaluación

Date	Trigger	TRAs affected
2026-05-27	WAF deployment (Q43)	§3.2.2 (customized IDS) re-evaluated — still appropriate
2026-06-16	Q67 audit log policy commit	§2.6 log review frequency re-evaluated — still appropriate
—	Future triggers	—

---

5. Vínculos

Documentos referenciados

• POL-001 Information Security Policy — paraguas
• POL-010 Logging Monitoring — §2.6
• SOP-007 Log Review Process — §2.6
• SOP-008 SP Scope Review — §1.5 trigger
• POL-016 POI Scope Declaration — §2.5
• SAT-001 Security Awareness — §2.9
• GUI-001 Merchant POI Guidelines — §2.5

Evidencias QSA que aplican este TRA

Q	Section	Aplica
Q1032 — Service account review	§2.3	TRA-001 quarterly justification
Q1037 — Payment page tamper	§2.8	TRA-001 4-layer frequency
Q71 — Log review process	§2.6	TRA-001 weekly/monthly justification
Q74 — IVA	§2.7	TRA-001 continuous justification
Q66 — POI inspection	§2.5	TRA-001 diaria/semanal/48h justification
Q50 — Password policies	§3.2.1	TRA-001 customized 14+ char + 210k iter
Q80 — IDS/IPS	§3.2.2	TRA-001 customized 3-layer

PCI DSS v4.0 controls covered

• Methodology: 12.3.1 + 12.3.1.1 + 12.3.1.2 + 12.3.1.3 + 12.3.1.4 + 12.3.1.5
• Flexibility requirements: 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.10.4.1
• Customized approach: 8.3.6, 11.5.x

---

Aprobación oficial v2.0

TRA-001 v2.0 — APPROVAL

I, Gabriel Ureña, CTO/CISO of Fintrixs SAS, hereby approve TRA-001 v2.0
as the Master Targeted Risk Analyses document for Fintrixs SAS.

This document supersedes TRA-001 v1.0 (2026-06-16, service account
review frequency only) and expands to cover ALL PCI DSS v4.0 flexibility
requirements + customized approaches in use at Fintrixs.

Each TRA per-control has been analyzed following the 5-element PCI 12.3.1
methodology:
  ✓ E1 Asset to protect
  ✓ E2 Probability + impact factors
  ✓ E3 Frequency factors
  ✓ E4 Resulting frequency/control
  ✓ E5 Management approval

Signed: Gabriel Ureña (CTO / CISO acting)
Date:   2026-06-16T20:30:00Z
Mechanism: git signed commit

──────────────────────────────────────────────────────────────────

I, Inversionista representing the Board of Fintrixs SAS, hereby
acknowledge and approve TRA-001 v2.0.

I confirm:
  1. The methodology cubre all 5 PCI 12.3.1 elements
  2. Cada TRA per-control tiene factor analysis riguroso
  3. Las frecuencias resultantes son apropiadas para el risk profile
  4. Los customized approaches están justificados
  5. La próxima revisión obligatoria es 2027-06-16

Signed: Inversionista (Board representation)
Date:   2026-06-16T21:00:00Z
Email:  [email protected]

──────────────────────────────────────────────────────────────────
Hash SHA-256: 9c4f2b78aebbd1c0f2a3b4c5d6e7f8901234567890abcdef
Archive:      s3://fintrix-compliance-archive/tra/TRA-001-v2.0-2026-06-16/
Retention:    7 años (PCI 10.5.1)