Skip to content
HACKTECH

Compliance

What each framework asks you to test, and how soon it wants an incident reported.

Some frameworks name a penetration test and how often to run it: every 12 months under PCI DSS and NYDFS Part 500, every 18 months for a high-security database under Israel's Data Security Regulations, and every three years for the DORA entities their authorities select for threat-led testing. Most of the rest ask for regular testing or evaluation and leave the interval to your risk assessment, so you need to be able to defend the one you choose. Incident clocks vary as widely: a severe incident goes to Israel's Privacy Protection Authority immediately, DORA's initial notification of a major incident is due within 4 hours of classifying it, and HIPAA allows up to 60 days to notify the people affected. Each section gives article and requirement numbers and lists its sources, checked against the regulators' and standards bodies' own texts where those are public. This is a practitioner's summary, not legal advice.

16 frameworksFacts checked

Testing duties and incident clocks, side by side

One line per framework, grouped by where it binds. The full requirement, with article and requirement numbers, is in each framework's section below.

Scroll the table sideways to see every column.

Testing requirements and incident clocks for 16 frameworks, checked 9 November 2026
FrameworkApplies toWhat it says about testingIncident clock
Israel
Privacy Protection Law, Amendment 13Controllers and processors of personal data in IsraelNo interval of its own; attaches fines to the tests the Regulations requireImmediately, through Regulation 11(d); late reports are fined
Data Security RegulationsEvery Israeli database of personal data, by security levelHigh: risk assessment and pentest every 18 months; medium and high: audit every 24 monthsSevere incidents to the PPA immediately (Regulation 11(d))
Bank of Israel Directive 364Israeli banking corporations and systemically important payment providersA sufficient share of controls yearly; every control at least every three yearsTo the Supervisor of Banks, on Directive 366's criteria
European Union
GDPRProcessing in the EU, or of people in the EU from outside itA process for regularly testing security (Art. 32(1)(d)); no fixed interval72 hours from awareness to the supervisory authority
NIS2Medium and large entities in 18 critical sectors, through national lawEffectiveness assessment (Art. 21(2)(f)); a testing policy for digital providers24-hour early warning, 72-hour notification, final report in a month
DORA20 types of EU financial entity and their ICT providersYearly tests, weekly scans, TLPT every three years if selectedInitial notice 4 hours after classification, 24 after awareness; then 72 hours, a month
Cyber Resilience ActManufacturers of hardware and software sold on the EU marketEffective and regular security tests and reviews (Annex I, Part II, point 3)24-hour early warning and 72-hour notification through ENISA
AI ActProviders and deployers of AI in the EU; high-risk systems carry the heaviest dutiesAdversarial testing for systemic-risk models now; high-risk security from December 2027Serious incidents within 15, 10 or 2 days, by type (Art. 73)
United States
HIPAA Security RuleUS health plans, clearinghouses, providers and their business associatesRisk analysis and periodic evaluation; a yearly pentest only in the proposalIndividuals within 60 days of discovery; HHS and media by breach size
SEC disclosure rulesSEC registrants, foreign private issuers includedNone required; Item 106 asks whether you use outside assessorsForm 8-K four business days after deciding an incident is material
NYDFS Part 500Banks, insurers and others licensed under New York financial services lawAnnual pentest from inside and outside (500.5(a)(1)); risk-based scans72 hours to DFS; extortion payments within 24 hours
CMMC 2.0US defence contractors handling FCI or CUI, where the contract requires itLevel 1 self-assessment yearly; Level 2 assessment every three years72 hours from discovery to DoD (DFARS 252.204-7012)
Global
PCI DSS 4.0.1Anyone storing, processing or transmitting card data, or able to affect its securityQuarterly scans; pentests every 12 months and after significant change (11.4)No regulator clock; notify brands and acquirers per their procedures (12.10.1)
SOC 2Service organisations whose customers ask for independent assuranceNot mandated; CC4.1 and CC7.1 points of focus name pentests and scansNo fixed clock; customer contracts set notice periods
ISO/IEC 27001:2022Organisations seeking certification of their management systemAnnex A 8.8 and 8.29; internal audits at planned intervals (9.2)No external clock; Annex A 5.24 to 5.28 set the process
NIST CSF 2.0Any organisation, voluntarily, unless a contract or regulator adopts itVoluntary: ID.RA-01 and ID.IM-02 cover vulnerability work and testsNone; RS.CO-02 expects stakeholders to be notified of incidents

Israel

Israeli law and supervision: the privacy statute, the security regulations that carry its technical duties, and the Bank of Israel's directive for banks.

Israel

Israel Privacy Protection Law (Amendment 13)

Israeli statute; Amendment 13 in force since 14 August 2025

Amendment 13 to the Protection of Privacy Law, 5741-1981, was approved by the Knesset on 5 August 2024 and took effect on 14 August 2025. The Privacy Protection Authority (PPA) calls it the most comprehensive update to Israeli privacy law since 1981. It narrows database registration, makes some organisations appoint a privacy protection officer and gives the PPA administrative fines. The technical controls still come from the Data Security Regulations; what changed is the cost of ignoring them. In July 2026 the PPA imposed its first fine under the new powers, for a breach reported about two months late.

Who it applies to

Controllers of databases of personal data, and the holders (processors) that work on them. A privacy protection officer is mandatory for public bodies (other than security bodies) and the holders of their databases, for data traders whose database covers more than 10,000 people, where core activities involve regular, systematic monitoring of people on a significant scale (the Law names mobile operators and online search providers), and where the core activity is processing especially sensitive data on a significant scale, which the Law applies expressly to banks, insurers, general hospitals and health maintenance organisations. Registration is now needed only for data-trading databases covering more than 10,000 people and for certain public-body databases. Controllers of other databases with especially sensitive data on more than 100,000 people must notify the PPA within 30 days, attaching the database definitions document.

What it says about testing

The Law sets no testing interval of its own: the Data Security Regulations do, and Amendment 13 lets the PPA fine the gaps. At 2026 rates, failing to carry out the risk survey or penetration tests required for a high-security database sits in the top sanction tier, NIS 327,560, which may be doubled for a database holding data on 1,000,000 or more people. Gaps in the definitions document, the security procedure, incident records or access logging carry NIS 40,940 at medium security and NIS 163,780 at high. The PPA also sanctions gaps that did not cause the breach it is investigating: in September 2026 it fined the Beit Shemesh municipality NIS 64,000 because a vendor with ongoing access to its database systems for nearly two years was missing from the database definitions document, and its security procedure lacked the required outsourcing terms.

What it says about incidents

Reporting runs through Regulation 11(d) of the Data Security Regulations: a severe security incident in a medium- or high-security database goes to the PPA immediately, with the measures taken. Amendment 13 attaches a sanction to failing to report: at 2026 rates, NIS 81,890 for a medium-security database and NIS 327,560 for a high-security one. On 21 July 2026, in the first fine under the new powers, the PPA fined the Meuhedet health maintenance organisation NIS 256,000 after, according to Pearl Cohen, it reported a severe incident about two months after becoming aware of it.

Dates that matter

  1. The Knesset approves Amendment 13
  2. The PPA publishes its draft opinion on appointing a privacy protection officer for comment
  3. Amendment 13 takes effect, one year after publication
  4. Sanction amounts are index-linked to the consumer price index for the first time, as they will be every 1 January
  5. The PPA publishes its final opinion on the privacy protection officer duty, according to Lipa Meir & Co.
  6. First monetary sanction under Amendment 13: NIS 256,000 on Meuhedet for reporting a severe incident late

Engagements that produce the evidence

  • Database security audit: an evidenced account of who can reach each database and with which privileges, vendors included, so the database definitions document matches what the PPA would find.
  • Incident response: triage starts on the first call, so counsel learns early whether an incident counts as severe and must go to the PPA immediately, the duty behind the NIS 256,000 fine on Meuhedet in July 2026.
  • Threat modelling for new systems that will hold personal data, with the privacy protection officer in the room from the design stage.

Sources: Privacy Protection Law, Amendment 13

Back to the quick-reference table
Israel

Israel Privacy Protection Regulations (Data Security) 5777-2017

Binding regulations under the Privacy Protection Law, in force since 8 May 2018

The Protection of Privacy Regulations (Data Security), 5777-2017, published on 8 May 2017 and in force since 8 May 2018, are where Israeli law spells out technical security controls. Every database sits in one of four tiers: managed by an individual, basic, medium or high security. The tier decides the duties, from a database definitions document at every level and a written security procedure from basic up, to access logging, audits, penetration tests and immediate breach reporting at the top. Regulation 21 lists exactly which regulations apply at each level. The PPA publishes an English translation, but only the Hebrew text is binding.

Who it applies to

Every database of personal data under the Privacy Protection Law. Processors carry the controller's duties too, except the definitions document and the outsourcing agreement (Regulation 19). Medium security covers public bodies' databases, databases kept mainly to pass data to others, and databases of sensitive data such as medical, genetic, biometric, financial or criminal-record data, unless no more than ten people are authorised to use them. A data-trading or sensitive-data database is high security if it holds data on 100,000 or more people or has more than 100 authorised users, and for sanctions Amendment 13 also treats a database of biometric identifiers of 100,000 or more people as high security.

What it says about testing

At high security level the controller must carry out a data security risk assessment, and penetration tests of the database systems against external and internal threats, at least once every 18 months, discuss the results and fix the faults found (Regulation 5(c) and (d)). At medium and high level an internal or external audit is due at least once every 24 months, by an auditor trained in data security who is not the database's own security officer, reporting shortcomings and the fixes needed (Regulation 16); at high level it can be done together with the risk assessment. Medium and high databases also need an automated mechanism that logs access to the database systems, with the records kept for at least 24 months (Regulation 10). One risk assessment, penetration test or audit may cover several databases at the same level. According to DLA Piper, in May 2024 the PPA recommended risk assessments and penetration tests below the high level as well.

What it says about incidents

Every security incident is documented, at every level (Regulation 11(a)), and from the basic level up the security procedure must say how incidents are handled and reported internally (Regulation 11(b)). A severe security incident goes to the PPA immediately, with the measures taken (Regulation 11(d)). At high level that is any use of data without or beyond authorisation, or damage to data integrity; at medium level, the same affecting a substantial part of the database. The PPA may order the controller to notify the people who may be harmed, after consulting the head of the national cyber authority. Since a 2022 policy update the PPA expects the report on discovery or reasonable suspicion, replacing its earlier guidance of within 24 hours and no later than 72. Incidents are reviewed at least once a year at medium level and at least quarterly at high (Regulation 11(c)).

Dates that matter

  1. The Regulations are published (Regulations File 5777 no. 7809, page 1022)
  2. The Regulations take effect, one year after publication
  3. The PPA recommends risk assessments and penetration tests below the high level too, according to DLA Piper
  4. Amendment 13 attaches monetary sanctions to breaches of the Regulations
  5. First sanction for failing to report a severe incident immediately

Engagements that produce the evidence

  • Network & infrastructure testing scoped to Regulation 5(d): the database systems and every route to them, from the internet and from an ordinary employee device, then a free retest of every fixed finding within 30 days of report delivery, each marked fixed, partly fixed or still open.
  • Web application testing of the applications and APIs that use the data, with an account for every role, so use beyond authorisation is tested rather than assumed.
  • Database security audit against the CIS Benchmarks: the configuration, privilege and access-logging evidence an auditor asks for under Regulations 10 and 16.
  • Incident response: triage on the first call and a scope-of-compromise statement that answers the question Regulation 11(d) turns on, whether data was used without or beyond authorisation.
Back to the quick-reference table
Israel

Bank of Israel Directive 364

Bank of Israel directive; in force since 18 May 2026, replacing Directive 361

Proper Conduct of Banking Business Directive 364, Management of Information Technology Risks, Information Security and Cyber Defense, has set the cyber rules for Israeli banks since 18 May 2026; until then they came from Directive 361, Cyber Defense Management. Circular C-06-2799 of 18 November 2024 issued Directive 364, which took effect 18 months after publication and on that day repealed Directive 361 together with Directives 357 (information technology management) and 363 (supply chain cyber risk management). Contracts signed before publication must be brought into line at their next renewal, and no later than three and a half years after commencement.

Who it applies to

Banking corporations as defined in the Banking (Licensing) Law, 5741-1981, and systemically important payment service providers. Third parties with access to a bank's information assets are assessed and contracted against the directive by the bank, so technology vendors to Israeli banks meet it through their customers.

What it says about testing

Banks map their information security controls and test them through a systematic programme in which a sufficient portion of controls is tested at least once a year and every control at least once every three years (section 137.1). Controls are also tested after a material change in threats, vulnerabilities, the asset or its technology environment, and before a new information asset goes into use, while controls on assets exposed to environments where the bank cannot enforce its own policy are tested every year. Test types are chosen per control from a list that includes gap and compliance surveys, source code review, vulnerability surveys, controlled penetration attempts and red team tests (section 138.1). Success criteria, including when a retest is needed, are set in advance, and results go to senior management with recommended corrective actions.

What it says about incidents

Banks report technology failure and cyber events to the Supervisor of Banks under Directive 366, Reporting of Technology Failure and Cyber Events, which sets the reporting criteria. Directive 364 requires the bank's security capability to cover detecting and responding to events, including recovery, reporting and communication with the relevant parties about them.

Dates that matter

  1. Circular C-06-2799 publishes Directive 364
  2. Directive 364 takes effect, 18 months after publication; Directives 357, 361 and 363 are repealed

Engagements that produce the evidence

  • Red team & purple team exercises, one of the test types the directive lists, run against live detection and closed with a purple team session that turns the gaps into tuned rules.
  • Application security audit: source code review, another listed test type, with every finding tied to a file and a line.
  • Network & infrastructure and cloud configuration testing of the controls due in this year's share of the three-year cycle, with a free retest of every fixed finding within 30 days of report delivery.
  • Database security audit of the systems holding customer data, as the compliance survey for those controls.
Back to the quick-reference table

European Union

Several of these reach companies with no EU establishment: the GDPR when they offer goods or services to people in the EU or monitor them there, the Cyber Resilience Act and the AI Act when they place products or AI systems on the EU market, and NIS2 when they offer cloud, managed or other digital services in the EU.

European Union

GDPR

EU regulation, applies since 25 May 2018

The General Data Protection Regulation, Regulation (EU) 2016/679, has applied since 25 May 2018 to the processing of personal data in the EU, and to organisations outside it that offer goods or services to people in the EU or monitor their behaviour there (Article 3(2)). Israel's adequacy decision from the European Commission lets personal data flow from the EU to Israel without extra safeguards, but it does not take an Israeli company's EU-facing processing out of scope. The GDPR sets no testing interval. It asks for security appropriate to the risk, a process for testing it regularly, and breach notification within 72 hours.

Who it applies to

Controllers and processors established in the EU, and those outside it whose processing relates to offering goods or services to people in the EU or monitoring their behaviour there. A controller or processor outside the EU that is caught by Article 3(2) generally has to designate a representative in the EU in writing (Article 27).

What it says about testing

Article 32 requires security appropriate to the risk, including, as appropriate, a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures (Article 32(1)(d)). No interval is set, so the controller chooses one and must be able to justify it. Dated penetration tests, audits and retests are the plainest evidence that the process exists and runs. Infringements of Articles 25 to 39, Article 32 included, can be fined up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher (Article 83(4)(a)).

What it says about incidents

The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to people; a late notification must give reasons (Article 33(1)). The EDPB treats a controller as aware once it is reasonably certain that a security incident has compromised personal data, and the information may follow in phases (Article 33(4)). A processor tells its controller without undue delay (Article 33(2)). Where the risk to people is high, they must be told too, without undue delay (Article 34(1)), and every breach is documented whether or not it is notified (Article 33(5)). A Commission proposal to notify only high-risk breaches, within 96 hours, is still a proposal: 72 hours remains the law.

Dates that matter

  1. Published in the Official Journal
  2. Applies across the EU
  3. The EDPB adopts version 2.0 of its breach notification guidelines (Guidelines 9/2022)
  4. The Commission proposes the Digital Omnibus, with a 96-hour, high-risk-only notification duty (not adopted)

Engagements that produce the evidence

  • Web application testing on a schedule you can defend, with dated reports and retests that show the Article 32(1)(d) process running rather than only written down.
  • Incident response that puts in writing, as early as the evidence allows, whether personal data was compromised; the 72 hours run from that point, and Article 33(4) lets the details follow in phases.
  • Cloud configuration review of where the personal data actually lives: buckets, snapshots, backups and the identities that can read them.
  • Database security audit of access, encryption and logging on the databases that hold personal data.

Sources: GDPR

Back to the quick-reference table
European Union

NIS2

EU directive, applied through each Member State's national law

Directive (EU) 2022/2555, NIS2, came into force in January 2023 and covers, as a rule, medium-sized and large entities in 18 critical sectors, classed as essential or important. Member States had to transpose it by 17 October 2024 and apply it from 18 October 2024, but many were late: on 7 May 2025 the Commission sent reasoned opinions to 19 of them. Your obligations therefore come from the national law of each Member State with jurisdiction over you, and start when that law does; in Germany, for example, entities have been covered since 6 December 2025. Management bodies must approve and oversee the measures and follow training, and can be held liable for infringements.

Who it applies to

Essential and important entities in the sectors listed in the Directive's annexes, generally medium-sized and large organisations, under the law of the Member State with jurisdiction. Cloud computing, data centre and content delivery network providers, managed service and managed security service providers, DNS service providers and top-level domain registries, online marketplaces, search engines, social networks and trust service providers also fall under Implementing Regulation (EU) 2024/2690, which sets their technical requirements in detail. All of them except trust service providers must designate a representative in the EU if they offer services there without being established there (Article 26(3)).

What it says about testing

Article 21 lists the minimum risk-management measures, among them security in acquisition, development and maintenance, including vulnerability handling and disclosure, and policies and procedures to assess whether the measures are effective (Article 21(2)(e) and (f)). For the digital entities it covers, Implementing Regulation (EU) 2024/2690 makes testing explicit: a security testing policy, risk-based decisions on the need, scope, frequency and type of tests, testing to a documented methodology, a record of each finding's criticality and the mitigation taken, and mitigation of critical findings (Annex, point 6.5). Its recitals give penetration tests, vulnerability scanning, static and dynamic application security tests, configuration tests and security audits as examples. Neither text sets a fixed testing interval.

What it says about incidents

Significant incidents go to the national CSIRT or competent authority in stages: an early warning without undue delay and within 24 hours of becoming aware; an incident notification within 72 hours, with an initial assessment of severity and impact and indicators of compromise where available; and a final report no later than one month after the notification, or a progress report if the incident is still being handled, with the final report one month after it is (Article 23(4)). Trust service providers notify incidents affecting their trust services within 24 hours. These deadlines bind you through national law, which can add detail.

Dates that matter

  1. Published in the Official Journal
  2. Deadline for Member States to adopt and publish their transposing laws
  3. National measures apply and the original NIS Directive is repealed
  4. Implementing Regulation (EU) 2024/2690 enters into force
  5. The Commission sends reasoned opinions to 19 Member States over incomplete transposition
  6. Germany's NIS2 rules cover entities, according to the BSI
  7. The Commission proposes targeted amendments (COM(2026) 13), still before Parliament

Engagements that produce the evidence

  • Cloud configuration review and network & infrastructure testing to a documented methodology, with each finding's criticality and mitigation recorded: the record point 6.5 of the Implementing Regulation asks for.
  • Red team & purple team exercises that show whether detection and response work, evidence for the effectiveness assessment in Article 21(2)(f).
  • Incident response that works to the 24-hour early warning: triage on the first call, with indicators of compromise captured in time for the 72-hour notification.
  • Web application testing reports that open with an executive summary a management body can read, now that Article 20 makes it approve and oversee the measures.

Sources: NIS2

Back to the quick-reference table
European Union

DORA

EU regulation, applies since 17 January 2025

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of EU financial entity, from banks and insurers to investment firms, and to the ICT third-party service providers they rely on, with EU-level oversight of providers designated as critical. Its testing duties are precise: yearly tests of the systems that support critical or important functions, automated vulnerability scanning of those assets at least weekly, and threat-led penetration testing at least every three years for the entities their authorities select. The initial notification of a major incident is due within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of it.

Who it applies to

Financial entities in the EU, 20 types in all, including credit institutions, payment and electronic money institutions, investment firms, insurers, trading venues and central counterparties, and the ICT third-party service providers that serve them. Microenterprises and the entities on DORA's simplified ICT risk management framework (Article 16) are excluded from threat-led testing.

What it says about testing

Entities other than microenterprises must test all ICT systems and applications supporting critical or important functions at least yearly, as part of their resilience testing (Article 24). The Commission's regulatory technical standards on ICT risk management add automated vulnerability scanning of the ICT assets supporting those functions at least weekly (Article 10(2)). Entities identified by their authorities must run threat-led penetration testing (TLPT) on live production systems at least every three years (Article 26). Under Delegated Regulation (EU) 2025/1190, drafted in line with TIBER-EU, active red teaming lasts at least 12 weeks, the red team report is due within 4 weeks of its end, and the blue team report, replay and purple teaming within 10 weeks. Entities using internal testers must contract external ones every third test, and significant credit institutions may use external testers only.

What it says about incidents

Major ICT-related incidents go to the competent authority on the deadlines in Delegated Regulation (EU) 2025/301: an initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report no later than one month after the latest intermediate report. A deadline that falls on a weekend or bank holiday can move to noon on the next working day, except for initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and entities that are also NIS2 essential or important entities.

Dates that matter

  1. Published in the Official Journal
  2. DORA applies
  3. Incident reporting standards (Delegated Regulation (EU) 2025/301) enter into force
  4. TLPT standards (Delegated Regulation (EU) 2025/1190) enter into force

Engagements that produce the evidence

  • Red team & purple team exercises informed by TIBER-EU and ending in purple teaming, which give your blue team a rehearsal of the TLPT structure before a test authority is involved.
  • Network & infrastructure and cloud configuration testing of the systems behind critical or important functions, scheduled to the yearly Article 24 cycle.
  • Incident response: triage starts on the first call, so you can classify a major incident early and keep the full 4 hours for the initial notification instead of losing them to the 24-hour limit from awareness.
  • Application security audit of in-house software that supports critical or important functions, with every finding tied to a file and a line.

Sources: DORA

Back to the quick-reference table
European Union

EU Cyber Resilience Act

EU regulation; reporting duties since 11 September 2026, full application from 11 December 2027

The Cyber Resilience Act, Regulation (EU) 2024/2847, sets security requirements for hardware and software products with digital elements made available on the EU market, and puts the main duties on their manufacturers, so it reaches software and device makers outside the EU too. It entered into force on 10 December 2024. Manufacturers' reporting obligations have applied since 11 September 2026 to every product in scope, including those already on the market. The product requirements apply from 11 December 2027 to products placed on the market from that date, or substantially modified after it.

Who it applies to

Manufacturers of products with digital elements, hardware and software alike, that are made available on the EU market, with further duties for importers and distributors. Products that are not made available on the market, and some products covered by other EU legislation, fall outside it.

What it says about testing

Annex I requires products to be made available on the market without known exploitable vulnerabilities, on the basis of the manufacturer's cybersecurity risk assessment. Its vulnerability handling requirements oblige manufacturers to apply effective and regular tests and reviews of the product's security (Annex I, Part II, point 3). No frequency is set, so the manufacturer chooses one and should be able to show why it is enough.

What it says about incidents

Since 11 September 2026 manufacturers notify actively exploited vulnerabilities and severe incidents affecting their products to the coordinating CSIRT and ENISA at the same time, through ENISA's Single Reporting Platform: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure being available for a vulnerability, or within one month of the notification for a severe incident (Article 14). This applies to products already on the market as well as new ones. Breaches of Article 14 can be fined up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

Dates that matter

  1. Published in the Official Journal
  2. Enters into force
  3. Rules on notifying conformity assessment bodies (Chapter IV) apply
  4. Manufacturers' reporting obligations (Article 14) apply
  5. The Regulation applies in full

Engagements that produce the evidence

  • Application security audit of the product's source code, dependencies and build pipeline: a regular review that leaves a record of what was checked and what was fixed.
  • Web application testing and mobile application testing of the product and the backend it talks to, before each major release.
  • Threat modelling at design time, so the cybersecurity risk assessment the essential requirements rest on starts from real data flows.
  • Incident response, with the forensic analysis to confirm or rule out active exploitation of a product vulnerability, which decides whether an early warning is due through ENISA's Single Reporting Platform within 24 hours.

Sources: Cyber Resilience Act

Back to the quick-reference table
European Union

EU AI Act

EU regulation, applying in stages until 2 August 2028

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and applies in stages. Prohibited practices and AI literacy duties have applied since 2 February 2025 and obligations for general-purpose AI models since 2 August 2025; the general date of application, which brought in the Article 50 transparency rules, was 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, moved the high-risk requirements to 2 December 2027 for Annex III systems and 2 August 2028 for AI in Annex I products, which leaves time to build security testing into the conformity work.

Who it applies to

Providers and deployers of AI systems placed on the market or used in the EU, and providers of general-purpose AI models. The heaviest duties fall on high-risk systems, those listed in Annex III and those in products covered by the EU legislation listed in Annex I, and on general-purpose models with systemic risk.

What it says about testing

Article 15 sets accuracy and cybersecurity requirements for high-risk AI systems across their lifecycle, including resilience against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities, and names data poisoning, model poisoning and adversarial examples among the AI-specific attacks to prevent. Providers of general-purpose AI models with systemic risk must evaluate their models, including by conducting and documenting adversarial testing (Article 55(1)(a)). The high-risk duties apply from 2 December 2027 or 2 August 2028; the general-purpose duties already apply.

What it says about incidents

Providers of high-risk AI systems report serious incidents to the market surveillance authorities of the Member States where they occurred: immediately once a causal link is established or reasonably likely, and no later than 15 days after becoming aware; no later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure; and no later than 10 days where a person has died (Article 73). Providers of general-purpose models with systemic risk keep track of, document and report serious incidents and possible corrective measures to the AI Office, and where appropriate to national authorities, without undue delay (Article 55(1)(c)).

Dates that matter

  1. Enters into force
  2. Prohibited practices and AI literacy obligations apply
  3. Obligations for general-purpose AI models and the governance rules apply
  4. The Digital Omnibus on AI enters into force and moves the high-risk dates
  5. General date of application, including the Article 50 transparency rules
  6. New prohibitions added by the Omnibus apply, and generative AI systems placed on the market before 2 August 2026 must meet Article 50(2)
  7. High-risk requirements apply to Annex III systems
  8. High-risk requirements apply to AI systems in Annex I products

Engagements that produce the evidence

  • AI & LLM application testing: adversarial testing of your deployed model, prompts, retrieval and tools, with attack transcripts and a regression prompt set you re-run after every change.
  • Threat modelling of AI features before they ship, covering poisoned documents and prompt injection through tool output.
  • Application security audit of the code around the model, where its output reaches browsers, databases and downstream APIs.
  • Incident response that preserves the logs needed to establish whether the AI system caused a serious incident, the question the Article 73 clock turns on.

Sources: AI Act

Back to the quick-reference table

United States

US federal and state rules for health data, public companies, New York financial services and defence contractors.

United States

HIPAA Security Rule

US federal regulation; a January 2025 proposal to tighten it is not final

The HIPAA Security Rule, in 45 CFR Part 164, protects electronic protected health information held by US health plans, health care clearinghouses and providers, and by their business associates, which can include software and cloud vendors that handle that information for them. Today it asks for a risk analysis and a periodic evaluation rather than named tests. A proposal published on 6 January 2025 would add yearly penetration tests and six-monthly vulnerability scans, but it is still only a proposal: the 2026 Unified Agenda lists it as a long-term action, with final action projected for July 2027.

Who it applies to

Covered entities, meaning health plans, health care clearinghouses and health care providers that transmit health information electronically in connection with HIPAA transactions, and their business associates: the people and companies that create, receive, keep or transmit protected health information on their behalf.

What it says about testing

The current rule requires an accurate and thorough assessment of the risks and vulnerabilities to electronic protected health information (164.308(a)(1)(ii)(A)), security measures that reduce them to a reasonable and appropriate level (164.308(a)(1)(ii)(B)) and a periodic technical and nontechnical evaluation (164.308(a)(8)). It names no penetration test or scan interval; a test is one way to evidence the evaluation. The proposed rule (90 FR 898) would require penetration testing by a qualified person at least every 12 months, automated vulnerability scans at least every six months and a compliance audit at least every 12 months, with compliance due 180 days after the final rule takes effect.

What it says about incidents

Under the Breach Notification Rule, a covered entity notifies affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured protected health information (164.404(b)). A breach affecting 500 or more people is also reported to HHS at the same time, and one affecting more than 500 residents of a state or jurisdiction to prominent media serving it (164.408(b) and 164.406). Smaller breaches are logged and reported to HHS within 60 days of the end of the calendar year (164.408(c)). Business associates notify the covered entity without unreasonable delay and no later than 60 days after discovery (164.410).

Dates that matter

  1. HHS publishes the proposed Security Rule update (90 FR 898)
  2. The comment period on the proposal closes

Engagements that produce the evidence

Back to the quick-reference table
United States

SEC cybersecurity disclosure rules

US federal securities rules for SEC registrants; compliance required since December 2023

Adopted by the US Securities and Exchange Commission on 26 July 2023, these rules make public companies disclose a material cybersecurity incident on Form 8-K within four business days of deciding it is material, and describe their cybersecurity risk management, strategy and governance every year under Regulation S-K Item 106. Foreign private issuers make comparable disclosures on Form 6-K for material incidents and on Form 20-F for risk management. The rules prescribe no test, but they ask, in public filings, how you assess cyber risk and whether you use outside assessors.

Who it applies to

Companies registered with the SEC. Domestic registrants disclose on Form 8-K and in their annual report; foreign private issuers use Form 6-K and Form 20-F. Smaller reporting companies had until 15 June 2024 to comply with the incident disclosure rule.

What it says about testing

No test is required. Item 106 asks registrants to describe their processes for assessing, identifying and managing material risks from cybersecurity threats, including whether they engage assessors, consultants, auditors or other third parties in connection with those processes, and whether they have processes to oversee and identify risks from their use of third-party service providers (Item 106(b)(1)). An independent test gives that description something concrete to rest on.

What it says about incidents

Form 8-K Item 1.05 is due within four business days after the registrant determines that an incident is material, and the determination must be made without unreasonable delay after discovery. Disclosure can be delayed only if the US Attorney General determines that it would pose a substantial risk to national security or public safety, and registrants subject to 47 CFR 64.2011 have a separate, limited delay. We found no amendment to Item 1.05 in the SEC's rulemaking list or the Federal Register as of 9 November 2026.

Dates that matter

  1. The SEC adopts the rules
  2. The rules take effect
  3. Item 106 annual disclosure applies to fiscal years ending on or after this date
  4. Form 8-K Item 1.05 compliance begins
  5. Item 1.05 compliance begins for smaller reporting companies

Engagements that produce the evidence

  • Incident response that builds the timeline and the scope-of-compromise statement from evidence: the facts a disclosure committee needs to decide materiality without unreasonable delay.
  • Red team & purple team exercises against your live detection and response, with a dated record of what was caught and what was missed, an input to the processes by which management monitors incident detection under Item 106(c)(2)(ii).
  • Web application testing by an outside party, the kind of third-party assessment Item 106(b)(1)(ii) asks about, with an attestation letter for the file.
Back to the quick-reference table
United States

NYDFS Part 500

New York State regulation; every phase of the 2023 amendment in force since 1 November 2025

23 NYCRR Part 500 is the cybersecurity regulation of the New York State Department of Financial Services for the banks, insurers and other financial services companies it licenses. The Second Amendment took effect on 1 November 2023 and phased in over two years; its last requirements, multi-factor authentication for anyone accessing the entity's information systems and an asset inventory, have applied since 1 November 2025. It names an annual penetration test outright, sets a 72-hour notice clock and makes the highest-ranking executive and the CISO sign a compliance filing every April.

Who it applies to

Any person operating under, or required to operate under, a licence, registration, charter, certificate, permit, accreditation or similar authorisation under New York's Banking Law, Insurance Law or Financial Services Law, even if other agencies also regulate it. Small entities can qualify for a limited exemption (500.19(a)), and larger Class A companies carry extra duties, including independent audits.

What it says about testing

Penetration testing of information systems from inside and outside their boundaries, by a qualified internal or external party, at least annually (500.5(a)(1)). Automated scans, with a manual review of systems the scans do not cover, at a frequency set by the risk assessment and promptly after any material system change (500.5(a)(2)). Vulnerabilities are remediated in time, prioritised by the risk they pose (500.5(c)). Class A companies must also design and conduct independent audits of their cybersecurity programme based on the risk assessment (500.2(c)).

What it says about incidents

Notify the superintendent as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the entity, an affiliate or a third-party service provider (500.17(a)). An extortion payment needs notice within 24 hours of paying and, within 30 days, a written explanation of why payment was necessary, the alternatives considered and the diligence done on sanctions rules, including OFAC's (500.17(c)). Every 15 April the entity files either a certification of material compliance or an acknowledgement of non-compliance with a remediation timeline, signed by its highest-ranking executive and its CISO (500.17(b)).

Dates that matter

  1. The Second Amendment takes effect
  2. The new notice rules in 500.17 apply, including the 24-hour extortion payment notice
  3. First annual filing as a certification or an acknowledgement of non-compliance
  4. Most new requirements apply, including the annual penetration test (500.5(a)(1))
  5. Governance, encryption, incident response and business continuity requirements apply
  6. Automated scanning, access privilege, endpoint detection and centralised logging requirements apply
  7. Multi-factor authentication for everyone and the asset inventory apply

Engagements that produce the evidence

  • Network & infrastructure testing from inside and outside the network boundary, the two vantage points 500.5(a)(1) names, with the testers' qualifications stated in the report.
  • Web application testing of customer-facing systems, with a free retest of every fixed finding within 30 days of report delivery, which records whether each fix was made.
  • Incident response that establishes quickly whether a cybersecurity incident has occurred, the determination that starts the 72-hour clock.
  • Social engineering assessment of help desk password resets and MFA re-enrolment, the processes the all-user MFA requirement now depends on.

Sources: NYDFS Part 500

Back to the quick-reference table
United States

CMMC 2.0

US Department of Defense contract requirement; Phase 1 in force, Phase 2 suspended

The Cybersecurity Maturity Model Certification programme, 32 CFR Part 170, checks that US defence contractors protect Federal Contract Information and Controlled Unclassified Information. The DFARS rule that writes it into contracts took effect on 10 November 2025 and started Phase 1, in which solicitations can require Level 1 or Level 2 self-assessment status. Phase 2, which would have required Level 2 certification by a third-party assessor from 10 November 2026, was suspended on 13 July 2026 pending a reform review, and we found no new date as of 9 November 2026.

Who it applies to

Contractors and subcontractors in the US defence supply chain whose contracts involve Federal Contract Information (Level 1) or Controlled Unclassified Information (Level 2 and above), where the solicitation includes the requirement. Level 2 is based on NIST SP 800-171 Revision 2; the programme rule states that Revision 3 does not currently apply.

What it says about testing

Level 1 needs a self-assessment every year. Level 2 needs an assessment every three years, either a self-assessment or, once Phase 2 resumes, a certification assessment by an authorised third-party assessment organisation (C3PAO), with an affirmation at each assessment and annually in between (32 CFR 170.15 to 170.17). The NIST SP 800-171 Revision 2 requirements behind Level 2 include scanning for vulnerabilities periodically and when new ones are identified (3.11.2), and assessing security controls periodically to determine whether they are effective (3.12.1).

What it says about incidents

Under DFARS clause 252.204-7012, a contractor that discovers a cyber incident affecting a covered contractor information system, or the defence information on it, must rapidly report it to the Department of Defense through its DIBNet portal, where rapidly means within 72 hours of discovery. It must also preserve images of the affected systems for at least 90 days from submitting the report.

Dates that matter

  1. NIST publishes SP 800-171 Revision 3, which CMMC does not yet use
  2. The CMMC programme rule (32 CFR Part 170) is published
  3. The programme rule takes effect
  4. The DFARS acquisition rule is published
  5. The DFARS rule takes effect and Phase 1 begins
  6. Phase 2 is suspended pending a CMMC reform review
  7. The original Phase 2 start for third-party Level 2 certification, now suspended

Engagements that produce the evidence

  • Network & infrastructure testing of the environment that holds Controlled Unclassified Information, which shows whether the boundary you assess against holds under attack.
  • Cloud configuration review of the cloud tenancy in assessment scope: identities, logging and the paths to CUI.
  • Incident response that preserves images of affected systems from the start, as DFARS 252.204-7012 requires for at least 90 days.
  • Database security audit of the databases holding CUI, as evidence for your self-assessment or your C3PAO; the CMMC status itself comes only from the assessment the rule prescribes.

Sources: CMMC 2.0

Back to the quick-reference table

Global

Standards that follow card data and customers across borders, and the voluntary NIST framework that other frameworks build on.

Global

PCI DSS 4.0.1

Industry standard from the PCI Security Standards Council; v4.0.1 is the only active version

The Payment Card Industry Data Security Standard is meant for every entity that stores, processes or transmits cardholder data or sensitive authentication data, or could affect the security of the cardholder data environment. Version 4.0.1, published on 11 June 2024 as a limited revision with no added or deleted requirements, has been the only active version since v4.0 retired on 31 December 2024. The 51 requirements v4.0 introduced as future-dated became mandatory on 31 March 2025, the payment-page script controls in 6.4.3 and 11.6.1 among them. It names its tests, how often they run and who may run them.

Who it applies to

Merchants and service providers that store, process or transmit cardholder data or sensitive authentication data, and any entity that could affect the security of the cardholder data environment. Service providers carry extra testing duties, and multi-tenant service providers must support their customers' external penetration tests (11.4.7).

What it says about testing

Internal vulnerability scans at least once every three months, with high-risk and critical vulnerabilities resolved and rescanned (11.3.1), performed as authenticated scans (11.3.1.2). External scans at least once every three months by a PCI SSC Approved Scanning Vendor (11.3.2). Internal and external penetration tests at least once every 12 months and after any significant infrastructure or application change, to a documented methodology that includes application-layer testing, by a qualified internal resource or third party that is organisationally independent but need not be a QSA or ASV (11.4.1 to 11.4.3). Exploitable vulnerabilities and security weaknesses found are corrected and the testing repeated to verify the corrections (11.4.4). Segmentation controls are tested at least every 12 months, and every six months for service providers (11.4.5 and 11.4.6). Payment pages need an authorised, integrity-checked inventory of scripts (6.4.3) and tamper detection at least weekly or as often as a targeted risk analysis sets (11.6.1); merchants on SAQ A instead confirm that their site is not susceptible to script attacks.

What it says about incidents

PCI DSS sets no regulator clock. Requirement 12.10.1 calls for an incident response plan ready to activate on a suspected or confirmed incident, covering roles, communication and contacts, including notification of the payment brands and acquirers at a minimum, an analysis of the legal requirements for reporting compromises, and the payment brands' own incident response procedures. Reporting deadlines therefore come from the brands' procedures and the law, not from PCI DSS itself. The plan is reviewed and tested at least once every 12 months (12.10.2), and named people are available around the clock to respond (12.10.3).

Dates that matter

  1. PCI DSS v3.2.1 is retired
  2. v4.0.1 is published
  3. v4.0 is retired, leaving v4.0.1 as the only active version
  4. The PCI SSC announces the revised SAQ A eligibility criteria
  5. FAQ 1588 clarifies the SAQ A script-attack criterion
  6. Future-dated requirements become mandatory, 6.4.3 and 11.6.1 included, and the revised SAQ A takes effect

Engagements that produce the evidence

  • Network & infrastructure testing to requirement 11.4: internal and external tests, segmentation testing where segmentation reduces scope, and a free retest of every fixed finding within 30 days of report delivery to verify each correction, as 11.4.4 requires.
  • Web application testing of the applications in and around the cardholder data environment, covering the application-layer testing 11.4.1 asks for.
  • Website security audit of payment pages against 6.4.3 and 11.6.1, with every third-party script inventoried with its owner, purpose and integrity status.
  • Incident response tabletop exercises that give the yearly 12.10.2 plan test a realistic scenario.

Sources: PCI DSS 4.0.1

Back to the quick-reference table
Global

SOC 2

Attestation report by an independent CPA firm, against AICPA criteria

A SOC 2 report is a CPA firm's opinion on a service organisation's controls, measured against the AICPA's 2017 Trust Services Criteria with points of focus revised in 2022. Security is the one category every report includes. The criteria describe outcomes rather than prescribe controls, so SOC 2 does not by itself require a penetration test, yet service organisations commonly give auditors test reports and remediation records as evidence. Revised criteria proposed in October 2026 would apply to engagements beginning on or after 31 December 2027, if approved.

Who it applies to

Service organisations whose customers want independent assurance over the systems that hold or process their data, such as software and cloud providers answering enterprise security reviews. A Type 1 report covers the design of controls at a point in time; a Type 2 report covers whether they operated effectively over a period.

What it says about testing

No test is mandated: your risk assessment sets the scope and frequency, and the auditor then tests what your control descriptions commit you to. Two points of focus name testing. CC4.1 lists penetration testing among the separate evaluations an entity can use, and CC7.1 calls for vulnerability scans periodically and after any significant change in the environment. If your system description promises an annual penetration test, the auditor will look for the report and for the remediation that followed.

What it says about incidents

No regulator and no fixed clock. The current criteria handle incidents under CC7.2 to CC7.5, from detecting anomalies to responding and recovering, and the 2027 draft would merge them into a single incident response criterion. Deadlines for telling customers come from your contracts and data processing agreements.

Dates that matter

  1. The AICPA announces the exposure draft of the proposed 2027 Trust Services Criteria
  2. The comment period on the exposure draft closes
  3. Proposed effective date: engagements beginning on or after this date, if approved

Engagements that produce the evidence

  • Web application testing scoped to the systems inside your report boundary, with an attestation letter dated after the retest for customers who ask.
  • Cloud configuration review when your SOC 2 scope reaches the infrastructure underneath the product.
  • Application security audit as one of the separate evaluations CC4.1 describes, for depth a black-box test cannot reach.
  • Incident response tabletop exercises that leave a dated record of your incident response plan being tested.

Sources: SOC 2

Back to the quick-reference table
Global

ISO/IEC 27001:2022

International standard; certificates issued by accredited certification bodies

ISO/IEC 27001 specifies an information security management system that an accredited certification body can audit and certify. The 2022 edition, published on 25 October 2022, reorganised its Annex A into 93 controls in four themes, organisational, people, physical and technological, down from 114 controls in 14 clauses. The transition period ended on 31 October 2025, when certificates still based on the 2013 edition expired or were withdrawn, so any certificate a supplier shows you now should cite the 2022 edition.

Who it applies to

Any organisation that seeks certification, for the scope it defines. The Statement of Applicability records which Annex A controls apply to that scope.

What it says about testing

No fixed test interval. Annex A control 8.8, management of technical vulnerabilities, expects you to identify technical vulnerabilities, evaluate your exposure to them and act, and control 8.29 covers security testing in development and acceptance; vulnerability scans, penetration tests and application security testing are the usual evidence for both. Clause 9.2 requires internal audits of the management system at planned intervals, and certification audits look for that record.

What it says about incidents

No external reporting duty or clock. Annex A controls 5.24 to 5.28 cover incident management from planning and preparation through assessment, response and learning to the collection of evidence, and control 6.8 covers how people report security events. Reporting deadlines come from the laws and contracts that apply to you.

Dates that matter

  1. ISO/IEC 27001:2022 is published
  2. IAF MD 26:2023 sets the transition rules for certification bodies
  3. From this date at the latest, initial certifications and recertifications use only the 2022 edition
  4. The transition ends; certificates based on the 2013 edition expire or are withdrawn

Engagements that produce the evidence

Back to the quick-reference table
Global

NIST CSF 2.0

Voluntary framework from the US National Institute of Standards and Technology

The NIST Cybersecurity Framework 2.0 (NIST CSWP 29), published on 26 February 2024, is voluntary. NIST describes it as a foundational resource that may be adopted voluntarily or through government policies and mandates, by organisations of any size and sector, and not specific to any country. It arranges cybersecurity outcomes under six Functions, Govern, Identify, Protect, Detect, Respond and Recover, with Govern new in this version. Other frameworks build on the CSF: NIST's CSF 1.1 international resources page lists Israel's Cyber Defense Doctrine 2.0, from the Israel National Cyber Directorate, as an adaptation, a category it uses for versions that draw substantially on CSF 1.0 or 1.1.

Who it applies to

Any organisation that chooses to use it, of any size, sector or country. It binds no one by itself, and becomes a requirement only where a contract, a regulator or a government policy adopts it.

What it says about testing

No test or interval is required. The outcomes testing serves include ID.RA-01, vulnerabilities in assets are identified, validated and recorded; ID.IM-01 and ID.IM-02, improvements are identified from evaluations and from security tests and exercises, including those done with suppliers and relevant third parties; and DE.CM-01, networks and network services are monitored to find potentially adverse events.

What it says about incidents

No reporting duty. The Respond Function covers managing, analysing, containing and eradicating incidents, and RS.CO-02 expects internal and external stakeholders to be notified, with response coordinated as laws, regulations or policies require. NIST SP 800-61 Revision 3, finalised on 3 April 2025, is the CSF 2.0 community profile for incident response and replaces the old four-phase life cycle with one built on the six Functions.

Dates that matter

  1. CSF 2.0 is published, adding the Govern Function
  2. SP 800-61 Revision 3 is finalised as the CSF 2.0 incident response profile

Engagements that produce the evidence

  • Red team & purple team exercises, the security tests and exercises ID.IM-02 draws improvements from, with detection gaps mapped to MITRE ATT&CK.
  • Cloud configuration review that identifies, validates and records vulnerabilities in cloud assets, the ID.RA-01 outcome.
  • Threat modelling for new systems, which turns risk outcomes into backlog items and test cases your team owns.
  • Incident response retainers and tabletop exercises aligned to SP 800-61 Revision 3, so the Respond and Recover outcomes have been rehearsed.

Sources: NIST CSF 2.0

Back to the quick-reference table

How an engagement becomes evidence

An auditor or regulator reviewing a test asks what was tested, by whom and when, what was found and what was done about it. Every penetration test, cloud configuration review and security audit we run produces four documents that answer those questions, in the order they are issued. Red team, social engineering, incident response, threat modelling and training engagements include no retest, so they close with the deliverables listed on each service page instead of a retest report and attestation letter.

  1. Written scope

    Before testing starts

    The scope statement you agree in writing after the scoping call, and the signed rules of engagement: named targets and environments, the approach, the roles and accounts used, testing windows, exclusions, the identifiers our traffic carries and the escalation contacts.

    How it is used: Shows which systems the test covered. A reviewer compares the named targets with the systems they care about before reading anything else.

  2. Report

    Two to three days after testing ends

    An executive summary, the scope and method with dates and the testers' qualifications, an attack narrative, every finding with reproduction steps, evidence and a CVSS 4.0 score, and a prioritised remediation plan.

    How it is used: The primary evidence for testing duties such as PCI DSS 11.4, NYDFS 500.5(a)(1), Regulation 5(d) and ISO/IEC 27001 control 8.8. Expect an auditor to read the scope, dates and method first, then ask what was decided about each finding.

  3. Retest report

    Within 30 days of report delivery, once you tell us what you fixed

    The report reissued, with every fixed finding retested against its original reproduction steps and marked fixed, partly fixed or still open.

    How it is used: Proves remediation, which several frameworks ask for explicitly: PCI DSS 11.4.4 wants corrections verified by repeat testing, Regulation 5(d) wants the faults found amended, and the NIS2 Implementing Regulation wants the mitigation of each finding recorded.

  4. Attestation letter

    After the retest

    A short statement of what was tested, when and how, and the status of every finding after the retest, without the technical detail that would help an attacker. Anything we have not verified as fixed stays open in the letter.

    How it is used: The document you send to customers and procurement teams who need assurance but not the full report. A QSA validating PCI DSS works from the full report, which, as Schellman notes (opens in a new tab), must show no open findings.

What an auditor checks before accepting a test

Recent enough
The report date against the framework's interval: within 12 months for PCI DSS 11.4 and NYDFS 500.5(a)(1), within 18 months for a high-security database under Regulation 5.
The right boundary
The scope against the boundary the framework draws: the cardholder data environment for PCI DSS, the systems in the report boundary for SOC 2, the database systems for Regulation 5.
Independent where required
PCI DSS 11.4 requires organisational independence of the tester, and Regulation 16 rules out the database's own security officer as its auditor.
Fixed and verified
A retest result for every finding marked fixed, and a documented risk decision for anything left open.
Consistent
The written scope, report, retest report and attestation letter name the same targets and dates, and your questionnaire answers say the same about how often you test.

Scope a test to the framework you answer to

Tell us which framework, which report and who will read it. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Book the scoping callHow incident response works