Skip to main content
Category: Regulatory Frameworks

Implementing Technical Standards

Also known as: ITS, Implementing Technical Standards on Supervisory Reporting
Simply put

Implementing Technical Standards (ITS) are detailed rules used within EU financial services to specify how certain regulatory requirements should be carried out in practice, such as the exact format and content of reports institutions must submit to supervisors. They are intended to create uniform, consistent requirements across the EU so that firms operate under fair and comparable conditions. ITS are distinct from broader legislation in that they focus on the practical, technical detail of implementation rather than setting high-level policy.

Formal definition

Implementing Technical Standards (ITS) are a category of EU technical standards, developed in draft form by supervisory authorities such as the European Banking Authority (EBA), that specify uniform conditions for implementing underlying legislative requirements, commonly covering the format, structure, and contents of supervisory reporting and disclosures. In the areas evidenced here, ITS address matters such as uniform reporting requirements, prudential disclosure specifications (including Pillar 3 disclosures on ESG risks), and reporting under specific EU regulations. ITS should be distinguished from Regulatory Technical Standards (RTS): both sit within the EU financial services rulebook and are typically issued as final draft standards by the relevant authority, but they serve different functions within the legislative framework. The evidence provided does not detail the full adoption process, legal force, or the precise scope distinction between ITS and RTS beyond their coexistence within EU financial services technical standards.

Why it matters

For institutions subject to EU financial services rules, Implementing Technical Standards (ITS) translate high-level legislative requirements into the precise, operational detail that firms must follow, most visibly the format, structure, and contents of supervisory reporting and prudential disclosures. This matters for third-party and supply chain risk professionals because many organizations depend on service providers, technology vendors, and outsourced reporting functions to prepare and submit these regulated returns. When an ITS changes the specification of a report, the practical burden of compliance often flows through to the vendors that build reporting systems or process the underlying data, making ITS a driver of change requests, contractual obligations, and testing cycles across the supply chain.

Because ITS are designed to create uniform reporting requirements and, in the EBA's framing, to help ensure fair conditions of competition, they reduce the variation firms would otherwise face across the EU. That uniformity can simplify due diligence and comparison where counterparties report on a consistent basis, but it also means that revisions, such as the EBA's final draft ITS amending the Pillar 3 disclosure framework on ESG risks, can affect many firms and their providers simultaneously. Programs that rely on third parties for regulatory reporting should treat ITS updates as events that may require coordinated vendor remediation rather than as isolated internal changes.

It is important not to overstate what an ITS covers. An ITS typically specifies the technical detail of how a requirement is carried out, for example, reporting format and content, rather than setting the underlying policy itself. The evidence here does not establish the full adoption process, legal force, or the precise scope boundary between ITS and Regulatory Technical Standards (RTS), so professionals should confirm the specific legal basis and applicability of any given standard rather than assuming a uniform effect across all sectors or jurisdictions.

Who it's relevant to

Compliance and regulatory reporting teams
Teams responsible for supervisory reporting rely on ITS to determine the exact format, structure, and contents of the returns they submit to competent authorities. They should track final draft ITS published by authorities such as the EBA, for example those covering charges data, prudential requirements, or Pillar 3 ESG disclosures, and confirm the specific legal basis and applicability of each rather than assuming uniform effect across all activities.
Third-party risk and vendor management professionals
Where reporting systems, data processing, or disclosure preparation are outsourced, ITS changes can flow through to service providers as change requests and contractual obligations. These professionals should treat ITS revisions as potential triggers for coordinated vendor remediation and verify that providers can meet updated reporting specifications, since compliance depends on the vendor's ability to implement the technical detail.
ESG and prudential disclosure specialists
Specialists working on Pillar 3 disclosures should monitor ITS amendments to the disclosure framework, including those addressing ESG risks, as these define the technical presentation of the required information. The ITS specify how disclosure is carried out rather than setting the underlying prudential policy, so specialists should distinguish the technical reporting requirement from the substantive obligations it supports.
Payment service and e-money providers
Firms in scope of EU payments regulation may be subject to ITS establishing uniform reporting, such as reporting under the Single Euro Payments Area Regulation. These providers, and any vendors supporting their reporting infrastructure, should confirm the specific ITS applicable to their activities and its reporting format requirements.

Inside ITS

Standardized Templates and Formats
ITS typically specify uniform templates, forms, and reporting formats that entities must use, promoting consistency and comparability across the parties subject to them. In a third-party risk context, this can shape how supervisory or disclosure data related to outsourcing and vendor arrangements is structured and submitted.
Uniform Procedures and Processes
ITS define common procedures for how requirements are to be carried out, aiming to ensure consistent application of an underlying framework rather than establishing new substantive obligations themselves.
Technical Specification of Existing Requirements
ITS operationalize obligations that already exist in higher-level legislation or regulatory technical standards. They address the 'how' of implementation and do not, on their own, create the underlying policy mandate.
Binding Character Upon Adoption
Once formally adopted through the applicable rulemaking process, ITS are typically binding on the entities within their scope, though their reach is confined to the specific matters and jurisdictions to which they apply.

Common questions

Answers to the questions practitioners most commonly ask about ITS.

Are Implementing Technical Standards the same as the underlying legislation they support?
No. ITS are not standalone primary legislation; they are technical instruments that specify uniform conditions for applying a higher-level legal act. They give effect to the detailed, technical aspects of a framework rather than establishing the substantive policy or obligations themselves, which are set in the parent legislation. Confusing the two can lead teams to overlook that the ITS derives its authority from, and is bounded by, the empowering act.
Do ITS and Regulatory Technical Standards (RTS) serve the same function and can they be treated interchangeably?
No. Although both are technical standards that support a broader legal framework, they are distinct instruments with different purposes. RTS typically specify substantive technical requirements that further develop the framework, while ITS focus on ensuring uniform application, often addressing standardized formats, templates, procedures, or reporting mechanisms. Treating them as interchangeable risks misidentifying which instrument governs a given obligation and where the applicable detail is located.
How should a third-party risk program locate which ITS provisions apply to a given obligation?
Trace the obligation back to its empowering provision in the parent legislation, then identify the ITS mandated by that provision. Because an ITS derives its scope from the empowering act, mapping the specific article or requirement to the corresponding ITS helps ensure you apply the correct standardized formats or procedures. In many programs this mapping is maintained alongside the broader obligation register so that changes to either instrument can be tracked.
What role do ITS-defined templates and formats play in vendor and supplier reporting?
Where an ITS specifies standardized templates, formats, or procedures, they typically govern how information is submitted or exchanged rather than what substantive obligation applies. In supplier-related reporting, this can mean aligning data fields, submission structures, or procedural steps to the prescribed format. Depending on the scope of the specific ITS, these requirements may cover only the presentation and transmission of information and not the underlying assessment or control expectations, which sit in other instruments.
How can teams keep implementation aligned when an ITS is amended?
Because an ITS specifies technical and often operational detail, amendments can change formats, procedures, or reporting mechanics without altering the substantive obligation in the parent act. In many programs, version control and change monitoring are applied to the ITS separately from the empowering legislation, so that procedural updates are captured and operational processes are adjusted accordingly. Relying on a single point-in-time reading of an ITS can leave implementation stale if amendments are not tracked.
What should implementers watch for regarding the boundary between an ITS and the obligations it supports?
Implementers should be careful not to read substantive obligations into an ITS that only specifies uniform conditions of application. The ITS is bounded by its empowering provision, so it cannot extend or create obligations beyond that mandate. Clarifying this boundary helps avoid over-applying technical detail as if it were the source of the requirement, and directs teams back to the parent legislation for the scope and substance of what is required.

Common misconceptions

ITS and Regulatory Technical Standards (RTS) are the same thing and can be used interchangeably.
They are distinct instruments. ITS focus on uniform conditions of implementation, such as standardized forms, templates, and procedures, whereas RTS typically address more substantive technical detail. Conflating the two obscures their different purposes and scopes.
ITS create new legal obligations for organizations and their third parties.
ITS generally do not establish new substantive requirements; they specify how existing obligations set out in higher-level legislation are to be implemented in a uniform manner. Treating them as a source of standalone mandates misstates their function.
Complying with ITS reporting formats means an organization's third-party risk is being managed effectively.
ITS primarily standardize the format and procedure of what is reported or submitted, not the quality or adequacy of the underlying risk management. Meeting a template requirement does not by itself indicate that inherent or residual third-party risk has been assessed, mitigated, or independently verified.

Best practices

Map each applicable ITS to the specific underlying legislative or regulatory obligation it implements, so that practitioners understand what substantive requirement is being operationalized rather than treating the ITS as a self-contained rule.
Distinguish ITS-driven format and procedural requirements from RTS-driven substantive requirements in internal policies and controls, avoiding conflation of the two instrument types.
Confirm the jurisdictional and sectoral scope of any ITS before applying it, since implementing technical standards apply only to defined entities and matters and expectations can vary across regions and regimes.
Use ITS-mandated templates and formats consistently across reporting cycles to preserve comparability, while recognizing that consistent formatting does not substitute for the underlying risk assessment or independent validation.
Track adoption and any subsequent revisions of relevant ITS through official rulemaking channels rather than relying on assumed version details, and update reporting processes when binding changes take effect.
Treat conformance with an ITS format as evidence of procedural compliance only, and pair it with separate controls that address the effectiveness of third-party risk identification, monitoring, and mitigation.
Promotional banner for the Pentest Readiness checklist download