RINP // CYBERSECURITY SERVICES
Resource CenterWhich service validates the effectivenessof which requirement?
The effectiveness of cybersecurity controls is assessed through verifiable findings produced from technical testing. This matrix relates Red in Pulse services to KVKK, ISO 27001, NIST CSF, SOC 2, OWASP, PCI DSS, BDDK, and EU AI Act requirements.
The mappings do not constitute a compliance attestation. The aim is to show, in audits, regulatory contexts, and customer security reviews, which control can be tested through which technical work and which report output supports it.
Service × framework mapping: where is which control's effectiveness proven?
Cells indicate the type of control-effectiveness evidence; cells with no direct match are left empty. Framework references (ISO Annex A, NIST subcategory, PCI Req, KVKK Art.) have been verified against the relevant source publication.
| Service \ Framework | KVKK 6698 | ISO/IEC 27001:2022 | NIST CSF 2.0 | SOC 2 (TSC) | OWASP ASVS 4.0 | OWASP API Top 10 (2023) | PCI DSS 4.0 | BDDK Information Systems Reg. | EU AI Act |
|---|---|---|---|---|---|---|---|---|---|
| Application Security Penetration Testing | Art. 12 technical measure: evidence of application-layer data access findings | A.8 (Technological Controls): application testing and secure development validation | PROTECT (PR.PS) and IDENTIFY (ID.RA): application vulnerability evidence | CC7.1 and CC4.1: control-effectiveness assessment through system monitoring | V1-V14 validation: coverage matrix and control effectiveness | API1-API10: evidence of authorization, identity, and business logic findings | Req 11.4: application-layer penetration testing methodology | Annual information systems penetration testing mandate, application track | - |
| Network Security Penetration Testing | Art. 12 technical measure: network and segmentation access evidence | A.8 (Technological): network security and segmentation validation | PROTECT (PR.AA, PR.PS): access control and network protection evidence | CC6.1 and CC6.6: logical access and network control effectiveness | - | - | Req 11.4 with Req 11.4.5: segmentation testing mandate | External and internal network penetration testing frequency mandate | - |
| Cloud Security Penetration Testing | Art. 12 technical measure: cloud privilege chain and data access evidence | A.5.23 (cloud services) with A.8: cloud provider control effectiveness | PROTECT with IDENTIFY (ID.AM, ID.RA): cloud asset and risk visibility | CC6.1 and CC6.7: cloud logical access and data transfer evidence | - | - | Req 11.4: applies to cloud-hosted CDE components | Cloud computing scope; regulation outsourcing rules | - |
| Social Engineering Simulation | Art. 12 administrative measure: awareness and human-layer measurement | A.6 (People Controls): awareness, recognize-and-report, and control effectiveness | PROTECT (PR.AT) and DETECT (DE.AE): awareness and reporting reflex | CC1.4 and CC2.2: unethical behavior signal and communication control | - | - | - | Operational risk regulation: measurement of human-driven vulnerabilities | - |
| Continuous Penetration Testing | Art. 12 technical measure: continuous validation and remediation evidence | A.8 (Technological) with A.5 governance: regular testing and trend reporting | DETECT (DE.CM) and GOVERN: continuous monitoring and management visibility | CC4.1 and CC7.1: remediate-and-verify cycle through continuous monitoring | V1-V14 cadence-based validation (optional ASVS alignment) | API1-API10 cadence-based revalidation | Req 11.4 annual and post-significant-change testing mandate | Annual penetration testing mandate with management visibility on a continuous cadence | - |
| Modular Red Team Simulation | Art. 12 technical measure: attack path and detection gap evidence | A.5.7 (threat intelligence) with A.8: attack path and detection evidence | DETECT, RESPOND, and RECOVER: detection gap and resilience | CC7.2 and CC7.3: anomaly monitoring and incident response control effectiveness | - | - | - | Operational risk and business continuity: attack path and resilience evidence | - |
| Generative AI Red Team | Art. 12 technical measure: GenAI runtime data and authorization evidence | A.5.23 with A.8: AI runtime control effectiveness | NIST AI RMF with GenAI Profile: runtime flow evidence | - | - | - | - | - | Art. 9 with Art. 15: high-risk system robustness and cybersecurity evidence |
| AI Model Supply Chain Assurance | Art. 12 with supplier management: model provenance evidence | A.5.19-22 (supplier) with A.8: model supply chain trust | NIST SSDF with AI RMF: release pipeline trust and BOM evidence | - | - | - | - | - | Art. 10 (data governance) with Art. 12 (record-keeping): model evidence package |
| AI for Penetration Testing and Red Team | - | A.5 governance: internal offensive workflow design and controlled pilot | GOVERN: internal process approval model and observability evidence | - | - | - | - | - | - |
What each framework requires and which service satisfies it
KVKK 6698: data security obligation
KVKK Art. 12, requiring the data controller to "take all necessary technical and administrative measures to ensure an appropriate level of security in order to prevent the unlawful processing of and access to personal data and to safeguard its retention," constitutes the primary basis for Red in Pulse services. Technical measure evidence is produced through PT-1, PT-2, PT-3, PT-5, and RT; administrative measure and awareness evidence through PT-4; AI-context data flow evidence through AIS-1 and AIS-2. The Board's "Personal Data Security Guide" counts penetration testing, security testing, and risk assessment among its recommended measures. Root cause analysis following a data breach notification (Art. 12/5) is also supported by attack path and control-effectiveness evidence.
ISO/IEC 27001:2022: Annex A control effectiveness
In the 2022 revision, Annex A has been consolidated to 93 controls and divided into four themes: A.5 Organizational, A.6 People, A.7 Physical, A.8 Technological. Red in Pulse services are used to validate ISMS control effectiveness: A.8 technological control effectiveness through PT-1/PT-2/PT-3/PT-5; A.5 governance and supplier (A.5.19-22) through AIS-2; A.6 awareness and human control through PT-4; A.5.7 threat intelligence and attack path evidence through RT. In the ISO 27001 certification audit, technical test findings and remediation verification feed the internal audit records. The certificate is not obtained from Red in Pulse; the certificate is issued by a certification body, while Red in Pulse produces the technical evidence of control effectiveness.
NIST CSF 2.0: six functions and subcategories
NIST CSF 2.0 (February 2024) reached six functions by adding the GOVERN function: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER. Red in Pulse services produce control-effectiveness evidence in every function: IDENTIFY (ID.RA risk assessment) through PT-1/PT-2/PT-3; PROTECT (PR.PS platform security, PR.AA access) through all penetration testing services; DETECT (DE.CM continuous monitoring, DE.AE event analysis) through PT-5 and RT; RESPOND and RECOVER resilience validation through RT; GOVERN (GV.RM strategic direction, GV.SC supply chain) through AIS-2 and AI-FOR-PT internal workflow design. The CSF is not a requirement on its own but a framework; the organization has the effectiveness of its self-selected subcategories tested.
SOC 2 Type II: Trust Services Criteria
SOC 2 reports are prepared against five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, Privacy. A Type II report tests control effectiveness over a period of time (typically 6-12 months). Red in Pulse penetration testing and continuous validation services produce concrete technical evidence for the effectiveness of Common Criteria CC4.1 (control assessment), CC6.1 (logical access), CC7.1 (system monitoring), and CC7.2 (anomaly monitoring). A SOC 2 report is frequently requested in the customer security reviews of SaaS providers; technical test findings appear on the auditor's test evidence list. The SOC 2 report is not obtained from Red in Pulse; it is obtained from an independent CPA firm, while the technical evidence production is carried out through Red in Pulse services.
OWASP ASVS 4.0: application verification standard
The OWASP Application Security Verification Standard (ASVS) 4.0 defines 14 verification categories, from V1 Architecture to V14 Configuration; three levels (L1/L2/L3) set coverage expectations for different risk profiles. When Application Security Penetration Testing (PT-1) and Continuous Penetration Testing (PT-5) are conducted in ASVS alignment, they produce control-effectiveness evidence in every V category. ASVS alignment is frequently requested in customer security reviews, product security requirements, and audits. ASVS is not a certification but a reference framework that measures verification level and scope.
OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 (2023 edition) lists ten risk categories specific to the API surface, from API1 Broken Object Level Authorization to API10 Unsafe Consumption of APIs. The theme of authorization, tenant boundary (multi-tenant), and business logic visibility is a fixed term of Red in Pulse Application Security Penetration Testing (PT-1); concrete technical evidence is produced in the validation of API1, API3 (Broken Object Property Level Authorization), and API5 (Broken Function Level Authorization). Cadence-based revalidation is performed in the same category through Continuous Penetration Testing (PT-5). The API Top 10 list is a control-effectiveness testing guide; it is not a compliance requirement, but it is frequently cited in customer reviews.
PCI DSS 4.0: cardholder data security
PCI DSS 4.0 (March 2022, v4.0.1 June 2024) is built on six goals and twelve core requirements. Req 11.4 sets the penetration testing methodology; it mandates annual and post-significant-change testing for external penetration testing (Req 11.4.3) and internal penetration testing (Req 11.4.4); segmentation testing (Req 11.4.5) is performed at six-month intervals. Red in Pulse Application Security (PT-1), Network Security (PT-2), Cloud Security (PT-3), and Continuous Penetration Testing (PT-5) satisfy this requirement for cardholder data environment (CDE) components. PCI compliance requires a QSA assessment; Red in Pulse produces a PCI-aligned evidence package, it does not issue a QSA report.
BDDK Information Systems Regulation
In the Turkish financial sector, the "Regulation on Banks' Information Systems and Electronic Banking Services" (BDDK, 15.03.2020) mandates information systems penetration testing at a minimum annual frequency; the "Regulation on Banks' Internal Systems and Internal Capital Adequacy Assessment Process" completes the operational risk management framework. Red in Pulse PT-1, PT-2, PT-3, and PT-5 services directly satisfy the penetration testing requirement for information systems within the regulation's scope; RT produces operational risk and resilience evidence. PT-4 provides administrative measure measurement in human-layer operational risk management. The regulation's scope and delivery format are prepared in alignment with audit reporting.
EU AI Act: high-risk system requirement
The EU AI Act (Reg. 2024/1689, in force 1 August 2024; high-risk provisions 2 August 2026) introduces obligations for high-risk AI systems covering risk management (Art. 9), data governance (Art. 10), record-keeping (Art. 12), transparency (Art. 13), human oversight (Art. 14), and accuracy-robustness-cybersecurity (Art. 15). Red in Pulse Generative AI Red Team (AIS-1) produces technical evidence for Art. 15 cybersecurity and robustness tests; AI Model Supply Chain Assurance (AIS-2) provides BOM, attestation, and registry evidence for Art. 10 data governance and Art. 12 record-keeping. The AI Act does not apply directly in Turkey; it is seen as a chain requirement among EU buyers to whom products are supplied in the Turkish market.
Customer security review, or audit and regulation?
// NEXT STEP
Let's talk about which requirement you want to validate
Framework mapping helps with orientation; the binding scope is defined through a discovery call and an approved SOW. Share which audit, regulatory, or customer-review priority you carry; let's plan the right services and concrete findings together.