AnlinaConsulting
ES
Segment · Compliance

Regulatory and market requirements

Requirements the organization is obliged to meet, substantiated requirement by requirement and with evidence. Not with a statement of intent.

Talk to Anlina
Frameworks we cover

Three obligations with three different origins: one is imposed by the payment brands, one is asked for by the market as a signal of maturity, and one began as European law and is becoming the common vocabulary of operational resilience.

Payment brand requirement

PCI DSS v4.0.1

The security standard for anyone who stores, processes or transmits cardholder data. Current version v4.0.1, with the requirements that were best practice until 31 March 2025 now mandatory in full.

International certification

ISO/IEC 27001:2022

The standard for information security management systems. 93 Annex A controls across four themes, plus Amendment 1:2024 on climate action.

Reference framework: DORA, Regulation (EU) 2022/2554

Digital operational resilience

The most developed framework on operational resilience, in force in Europe since 17 January 2025. It organizes the work along five pillars and is becoming the language the questions get asked in.

On other standards

Outside these three we claim no coverage. If your obligation is a different one, we will talk it through and tell you plainly whether we have something to add or whether you are better off with someone else.

Knowing you have to comply is not the same as being able to prove it

In nearly every organization there is a conviction that the requirements are met. What tends to be missing when the auditor, the acquirer or the supervisor arrives is the other half: being able to show, requirement by requirement, what that conviction rests on.

That distance between the compliance that is assumed and the compliance that can be evidenced is what this service measures and closes.

One methodology, three frameworks

The work runs the same way across all three standards. What changes is what it is measured against, and which artifacts each one demands.

  1. 01

    Scope

    What is in, what is out, and on what criterion the line was drawn. In PCI it is the cardholder data environment, in ISO the management system scope, in resilience the critical functions. The question is the same, and getting it wrong costs the same: it invalidates everything that follows.

  2. 02

    Evidence gathering

    Interviews by requirement family, configuration review, network and data-flow diagrams, and whatever documentation already exists. Nothing enters the report without something behind it.

  3. 03

    Requirement by requirement assessment

    Every requirement lands in an explicit state: met, partially met, or not met. Where it is partial, the report says exactly what is missing and what closing it would take.

  4. 04

    Risk analysis and prioritization

    Gaps are ordered by exposure and effort. PCI brings its own ordering through the six Prioritized Approach milestones; in ISO it comes from the risk assessment; in resilience, from how critical the affected function is.

  5. 05

    Roadmap and execution

    The assessment closes with a sequenced plan, with owners and dependencies. From there two paths: your team executes it, or Anlina supports the implementation.

Two ways to engage

Mode A

Gap analysis

A bounded engagement with a closing date. It ends with your current position documented and the roadmap to close it.

Mode B

Implementation and support

Executing the plan alongside your team: drafting policies, designing controls, preparing evidence and standing with you through to the audit or the supervisor's review.

What changes in each standard

Same method, three different sets of artifacts, and three boundaries worth stating from the outset.

PCI DSS v4.0.1

Who requires it

The payment brands, usually through your acquirer.

What is specific
  • The cardholder data environment scope, which the standard requires be confirmed at least every 12 months and upon significant change (12.5.2).
  • The portfolio of targeted risk analyses required by 12.3.1, which is a deliverable in its own right.
  • The responsibility matrix by requirement for every third-party service provider in scope (12.8).
  • Prioritization over the six milestones of the Prioritized Approach published by the PCI SSC.
Milestone 1135%
Milestone 210442%
Milestone 3146%
Milestone 44317%
Milestone 53213%
Milestone 64317%
PCI DSS v4.0.1 sub-requirements assigned to each milestone. Own tabulation over the Prioritized Approach for PCI DSS v4.0.1 document published by the PCI Security Standards Council, 249 sub-requirements mapped.

ISO/IEC 27001:2022

Who requires it

The market, as a signal of maturity, and increasingly clients through contract.

What is specific
  • The 93 Annex A controls across four themes: organizational, people, physical and technological.
  • The Statement of Applicability, where you justify which control applies, which does not, and why.
  • The risk assessment and treatment, which is what drives control selection.
  • The requirements in the main body of the standard: context, leadership, internal audit and management review.

Digital operational resilience

Who requires it

DORA, in the European Union, since 17 January 2025. In the region the vocabulary is already being adopted even while the local framework is still taking shape.

What is specific
  • ICT risk management as a formal framework rather than a scattered practice.
  • Incident classification and reporting with defined criteria and deadlines.
  • Digital resilience testing on the functions that cannot go down.
  • ICT third-party risk, including the register of contractual arrangements.
  • Threat information sharing with the rest of the sector.

What you are left with at close

The first four come out of any of the three standards. The last two appear when the standard calls for them.

  • 01

    Scope definition

    Formal, documented and defensible in front of an assessor.

  • 02

    Gap matrix

    Requirement by requirement, with its state and the evidence behind it.

  • 03

    Prioritized roadmap

    Sequenced by exposure and effort, with owners and dependencies.

  • 04

    Executive readout

    For the committee or the board, with the specific decision needed from them.

  • 05

    Risk analysis portfolio

    The targeted risk analyses in PCI DSS, or the risk treatment and Statement of Applicability in ISO 27001.

  • 06

    Third-party matrix

    Responsibility by requirement for every provider in scope, and the register of arrangements where it applies.

Other segments

OT security

Maturity assessment and consultancy on the industrial control environment.

PKI

Detailed design and implementation of public key infrastructure.

PCI DSS, PCI Security Standards Council, Qualified Security Assessor and Approved Scanning Vendor are trademarks of their respective owners. ISO and IEC are trademarks of their respective organizations. Anlina is not affiliated with the PCI Security Standards Council, is not a QSA and is not an accredited certification body: issuing a ROC, an AoC or a certificate is the role of the entities authorized to do so.

A scoping conversation, at no cost

To work out which standard you need to measure against, delimit the scope and size the effort on a realistic basis.

Talk to Anlina