Annex I Part I (2)(f) integrity: requirements and evidence

What Annex I Part I (2)(f) asks for and why it is hard to evidence

Point (2)(f) of Annex I Part I asks the manufacturer to show that the product protects the integrity of data, commands, programs and configuration against manipulation or modification that the user has not authorized, and that the product can report when corruption occurs. The scope is wide. It covers data at rest, data moving across networks or interfaces, data the product processes in memory, the code that runs it, and the settings that govern its behavior. If you are the compliance lead or the engineer who must answer for this point, your first job is to list which of those assets your product actually holds, in which states, and who or what is allowed to change each one. That list becomes the spine of your technical documentation and of the risk assessment that drives this decision.

Integrity is easy to claim and hard to prove because most products already do something that sounds like it. A signed package, a checksum on an update or a hashed password store can all be presented as integrity protection, yet none of them shows that a configuration file edited by a local administrator, a compromised service account or a malicious process is detected and reported. An assessor will ask where the baseline of trusted files and settings is recorded, who can change it, how a change outside an authorized path is noticed, and what the product records when it finds a corruption. Each answer needs a mechanism and a log entry, not a design statement. Confirm early whether your product can detect modifications on the device itself, or whether you rely on controls in the customer's environment, and document that boundary explicitly.

Which products, environments and data flows bring integrity into scope

For a product delivered as installable software, integrity covers the program files, the libraries it loads, its configuration files and the data it stores or processes locally. The question is which of these the user has not authorized to change, and which of them the product itself can be tricked into changing. Scope usually starts with the installed binaries and their configuration, then extends to local databases and any file the product reads as a command or instruction, such as plugin manifests or scripts.

Program and library files: Executables, shared libraries and bundled runtimes that the product loads on start-up.
Configuration files: Settings that change security behavior, such as logging levels, access rules or update channels.
Local data stores: Databases, caches and queues holding user or operational data.
Updates and logs as boundary decisions: Whether update packages and audit logs are inside the product boundary changes the work, because a tampered update path can defeat every other integrity control.

Confirm with your product team which of these files the product writes to after installation, and which of those writes the user is expected to make. Document the boundary in the risk assessment so the assessor can trace each in-scope item to a control.

How an assessor tests integrity protection and corruption reporting

This table compares what an independent assessor or notified body typically asks for when testing point (2)(f), column by column from test approach to evidence to common findings. Read it as a checklist of questions to prepare answers for before an assessment, not as a list of guaranteed outcomes. The main takeaway is that a baseline, a change detection setup and a record of reviewed alerts matter more than the tooling alone.

Assessment area	What the assessor typically asks	Evidence usually requested	Common finding
Scope of protected items	Which stored data, commands, programs and configuration are covered, and why those were chosen	Documented asset list tied to the cybersecurity risk assessment, with boot components, firmware, and configuration files identified	Configuration files or update channels left out of monitoring with no recorded rationale
Baseline integrity	How the known-good state was established and when it was last approved	Baseline checksums and attributes, change records, sign-off by the responsible owner	Baseline taken after deployment, so tampering before that point is never captured
Change detection configuration	Whether detection runs on a schedule or in real time and whether it covers creation, modification and deletion	Configuration exports of the monitoring agent or server, scan schedules and rule sets	Detection enabled on some hosts only, or deletions not reported
Access controls on protected items	Who can change the baseline, detection rules and the monitoring platform itself	Role assignments, access logs, separation between administrators of the product and of the monitor	The same account can alter files and suppress alerts about them
Alert records and review	Whether alerts reach a responsible person and what action followed	Alert history, triage tickets, documented investigations and closure notes	Alerts generated but no one reviews them, or review is undocumented
Corruption reporting to users	How the product tells the user that data or configuration has been corrupted	User-facing notification design, log entries, and documentation of the reporting path	Corruption detected internally but the user is never informed
Tampering simulation tests	Whether controlled modifications are detected and reported as designed	Test plans, test inputs, results showing detection and alerting, and remediation records	Tests run once at release and not repeated after updates or configuration changes
Ongoing maintenance	Whether the integrity controls stay current through the support period	Periodic review records, updated baselines after approved changes, and change management links	Baselines never refreshed, so approved updates trigger noise and reviewers ignore alerts

How to build integrity protection into a product in sequence

This sequence turns the Article 13(2) risk assessment into a tested integrity baseline, so the manufacturer can show that data, programs and configuration are protected against unauthorized change and that corruption is reported. Each step produces an artifact that the next step depends on.

Identify protected assets from the risk assessment
Start from the documented Article 13(2) cybersecurity risk assessment and list every asset whose unauthorized modification would matter: executable programs, boot components, configuration files, stored user data, command channels and update packages. The product security lead and the engineering owners of each component do this together, and the output is an asset register that names each item, its owner and the threat that makes integrity important for it. The step is done when every asset traces back to a risk entry and a point (2)(f) decision is recorded in the assessment.
Define integrity baselines for programs and configuration
For each protected program, boot component and configuration set, define what the known-good state looks like: file checksums, permissions, ownership, and the approved configuration values. Engineering writes these baselines from signed release builds and the approved reference configuration, not from a snapshot of a running system that may already be altered. The output is a versioned baseline file per product release, stored where it cannot be changed by the same process it is meant to check.
Define baselines for stored and processed data
Data does not have a fixed checksum in the way binaries do, so define integrity checks that fit each data store: database constraints, checksums or message authentication codes on records and messages, and tamper-evident logs for sensitive transactions. Confirm with the data architects which fields must be protected and how the product reports a mismatch. The output is a data integrity specification that lists each protected data class and the check that applies to it.
Select detection and signing mechanisms
Choose the tools that will detect changes and the mechanisms that protect the release artifacts themselves. File integrity monitoring such as Wazuh records a baseline of checksums and attributes and alerts on creation, modification or deletion, in real time or on a schedule. Verification jobs such as Bareos Verify compare files against cataloged attributes. Code signing and certificate issuance can run through FreeIPA's integrated Dogtag-based certificate authority or the OpenBao PKI secrets engine. Confirm that each tool supports the platforms and deployment model the product uses. The output is a tooling decision record with the reason for each choice.
Define authorized change paths
Write down every legitimate way the protected assets can change: signed vendor updates, administrator actions under change control, service accounts, and scheduled automated jobs. Each path needs a named actor, an authentication requirement, and a record that the change happened. Changes outside these paths are treated as unauthorized. The output is a change path matrix that the monitoring rules can enforce, so that an expected update does not trigger the same alert as an intrusion.
Build alert and reporting paths
Connect the monitoring and verification outputs to a triage process and to the reporting obligations the product must support. Define who receives an integrity alert, the severity levels, how the event is logged with who changed what and when, and how the product informs the user of a detected corruption. Check the Article 14 reporting obligations separately, because a corruption may also be a reportable vulnerability or incident. The output is a runbook and a tested alert route that shows an alert reaching a responder.
Test with deliberate modifications
Before release, make controlled, documented changes to protected files, configuration values and data in a test environment, including unauthorized edits, a deleted file and a changed boot component. Confirm that each change is detected, that the alert reaches the responder, that authorized updates pass without a false critical alert, and that a corrupted item is reported to the user as designed. Record each test case, the expected result and the actual result. The step closes when every test case has a pass record and any gaps are logged in the risk assessment.

Which open-source tools produce integrity evidence

Four open-source components can generate records that show whether data, configuration and certificates were changed without authorization. Each one produces a different kind of evidence, so the manufacturer should choose them against its own risk assessment and confirm what each one actually covers in its product.

Wazuh file integrity monitoring

Wazuh records a baseline of checksums and attributes for the files and directories you monitor, then alerts when a user or process creates, modifies or deletes one of them. Alerts can run on a schedule or in real time and include how and when a file changed and who changed it. For point (2)(f), the baseline and alert history can show that unauthorized modification was detected and reported. Confirm which paths your product's configuration and program files cover, how alerts reach your response process, and what the GPL-2.0-only license requires when you distribute Wazuh components with your product.

Bareos verify jobs

Bareos Verify jobs compare files on a system against the attributes already stored in its catalog, which gives a Tripwire-like check for changes made after a compromise. The result is a dated verification report that lists differing files, useful as evidence for backup integrity and for investigating modification. Confirm that your backup schedule covers the product's program and configuration data, that catalog records are protected from the same attacker, and the obligations that follow from the AGPL-3.0-only license if you modify and offer Bareos over a network.

FreeIPA certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates for hosts and services. Managed certificates let you show which identity was issued which certificate and when, which supports integrity of configuration that depends on trusted endpoints. Confirm how the CA keys are protected, how revocation is handled, and what the GPL-3.0-or-later license requires for any FreeIPA code you ship or modify.

OpenBao PKI secrets engine

The OpenBao PKI secrets engine issues dynamic X.509 certificates, so services receive certificates without anyone hand-generating a key and certificate signing request. Short-lived, automatically issued certificates reduce the window in which a stolen or altered credential stays useful, and issuance logs give an audit trail. Confirm the issuance policies and certificate lifetimes you configure, how the root and intermediate keys are stored, and the obligations under the MPL-2.0 license for modified OpenBao files you distribute.

Which evidence passes and how to keep it current between audits

What baseline records prove that file integrity is protected?

An assessor expects a signed or otherwise protected baseline of checksums and attributes for every monitored file, binary, boot component and configuration file, taken from a known-good build. The record should show which files are covered, the hash algorithm, when the baseline was captured, and who approved it. Keep one baseline per released version and per support branch, so an assessor can compare any field device or deployment against the baseline it shipped with. When a legitimate update changes files, generate a new baseline from the signed release artifacts rather than overwriting the old one, so the history stays intact. Ask your implementation partner to document how baselines are stored, who can write to them, and how they are retrieved for a given version.

How do I show that change detection is configured and covers the right scope?

Show the monitoring configuration itself, the list of monitored paths, the schedule or real-time mode, and the rules that exclude expected volatile paths. Wazuh file integrity monitoring, for example, is configured in the agent settings, where directories are listed with options for real-time monitoring, reporting of changes and the attributes compared. Store that configuration in version control so every change to scope has a commit, author and review. An assessor will compare the monitored scope against the product's technical description and risk assessment, so any exclusion needs a written reason. Confirm the exact configuration keys and defaults against the current Wazuh documentation for the version you deploy.

What do alert samples need to show for integrity detection to count?

Alert samples should show a real or controlled change being detected, the alert being generated, and the record reaching the place where it is reviewed. A good sample includes the file path, the attribute that changed, the old and new values, the time, and the process or user responsible. Keep samples from each release line and each monitored class, such as firmware, boot loader and application configuration. Test alerts on a schedule, for example by modifying a test file in a non-production environment, and retain the output as evidence that detection still works. Make sure the sample is taken from the production logging pipeline, not from a lab copy, since assessors ask whether the control works where the product runs.

How should records of authorized changes and their approvals be kept?

Every legitimate change to a monitored file should link to an approved change record, so each alert can be matched to a ticket, a signed release or a documented maintenance action. Assessors look for the trail from alert to approval, including who approved the change and when. Use the same workflow for product updates, configuration changes and key rotations, and require that the approval happens before deployment where possible. Unmatched alerts are the signal that matters most, so review them regularly and record the outcome. The organization owns this process; an implementation partner can design the workflow and the record format, but the approvals must come from people inside the organization.

What do corruption and incident reports need to contain under point (2)(f)?

Point (2)(f) requires products to report on corruptions, so the report should describe what was modified, how it was detected, what the product or operator did in response, and whether the change was authorized. Include the timestamp, affected asset, detection source, containment steps, and the decision on whether the event is reportable under Article 14. Keep the reports together with the baseline and the approval records, so the assessor can follow one event end to end. Confirm with counsel and your CSIRT contact what counts as an actively exploited vulnerability or severe incident, since the Article 14 reporting duty has applied since 11 September 2026 and the reporting platform is operated by ENISA.

What tampering test results prove detection works after a compromise?

Tampering tests show that an attacker or faulty process cannot change monitored files without detection. Run controlled tests that modify binaries, configuration and boot components, and record that the change was flagged and the verification failed. Bareos Verify jobs can compare files against previously cataloged attributes, which gives a Tripwire-like check for changes after a break-in, so include a restore or verify run in the test plan. Repeat the tests after each major release and after changes to the monitoring configuration, and keep the scripts, inputs, outputs and tester identity. Tests run by a security testing team add independent evidence, but the results should be owned and reviewed by the product team.

Which access control records protect baselines, keys and certificates?

Assessors expect records showing who can read, write and delete baselines, monitoring configuration, signing keys and certificates, and that these rights are reviewed. Store baselines in a location the monitored system cannot modify, and restrict write access to the release pipeline. For certificate issuance, FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue dynamic X.509 certificates so services do not handle manual key and signing request steps. Keep access logs for these systems, export access reviews on a fixed schedule, and document who holds break-glass access. Confirm the audit logging and role model in the current FreeIPA and OpenBao documentation before you rely on them as evidence.

How do I keep integrity evidence current across the whole support period?

Evidence goes stale when the product changes, so tie each artifact to a release identifier and schedule reviews on the same cadence as the product's update cycle. Regenerate baselines with each release, rerun tampering tests after changes to scope, and review alert samples and unmatched alerts at a fixed interval. Set a review of the risk assessment whenever a monitored component changes, because point (2)(f) applies to the product as it is supported. The support period is set by the manufacturer under the regulation, so confirm with counsel the length that applies to your product. Your internal owner should be named for each artifact, with a date of last review.

What meeting point (2)(f) costs in money and effort

This table lists the cost components of meeting point (2)(f) and marks each as one-time or recurring, who is paid, and what moves it up or down. No supplied fact gives prices for this point, so the table shows where effort sits, not what it costs. Use it to structure a written scope and to compare quotes line by line.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Engineering time to design integrity baselines and detection rules	Internal engineers, or an implementation partner under a fixed-scope agreement	One-time, then recurring when baselines change	Number of product components, configuration surfaces and data stores in scope; reuse of a documented baseline pattern
Tooling licenses and open-source tool operation	Open-source projects carry no license fee; the organization or partner pays for the operating effort	Recurring	Removing license spend does not remove operating effort: installation, upgrades, tuning and access control for the integrity tooling still need staff time
Hosting and storage for logs, checksums and baselines	Organization's cloud account, data center or air-gapped environment	Recurring	Volume of monitored files, scan frequency, retention period set by the risk assessment, and whether logs are replicated for tamper resistance
Testing of tampering and corruption scenarios	Internal QA, security testers or an external testing firm	One-time per release, then recurring with each major change	Number of data flows and command paths covered; whether tests include unauthorized configuration changes and detection of corruption events
Ongoing review and triage of integrity alerts	Operations or security staff, or a managed support retainer	Recurring	Alert noise from tuning, number of monitored assets, and whether alert routing to the vendor or operator is defined in advance
External penetration testing or design review of integrity controls	Independent security testing firm	Periodic, often one-time for the initial design	Depth of scope, number of interfaces that can alter data or configuration, and whether the review covers the update channel as well
Assessor sampling and evidence preparation	Independent conformity assessor, paid by the manufacturer; internal staff prepare evidence	Recurring at each assessment	How well baselines, alert records and corruption reports are indexed; the number of product versions the assessor samples
Documentation of the integrity design and risk assessment link	Internal compliance or product staff, or a readiness partner	One-time, then updated when the design changes	Clarity of the link between the Article 13(2) risk assessment and the chosen integrity controls

Where integrity controls usually fall short in assessments

Assessors testing Annex I Part I (2)(f) rarely fail a product because it has no integrity tooling at all. They fail it because the controls were set up late, cover the wrong files, or cannot show who changed what. The cards below cover the gaps that come up most often and what to change before the assessment.

Baseline taken after release

A baseline captured after the product ships only proves the state of the product on that day, not that it was unchanged before. Tools such as Wazuh record checksums and attributes of monitored files and compare later states against that record. Capture the baseline from the known-good build in the release pipeline, store it outside the product, and confirm that the first comparison in the field uses it.

Configuration files left unmonitored

Teams often monitor binaries and skip the files that change behavior, such as configuration, service units, certificate stores and boot settings. Point (2)(f) covers configuration explicitly, so the monitored scope should follow the risk assessment rather than the install directory. List every configuration path the product reads, and check that each one appears in the monitoring policy.

No record of authorized changes

An alert that a file changed does not show whether the change was approved. Assessors look for a link between each detected modification and an authorized action, such as a signed release, a change ticket or a maintenance window. Keep update and configuration workflows logged with the actor and reason, so that a detected change can be matched to an authorized event or investigated as unauthorized.

Alerts routed to nobody

Integrity monitoring that writes alerts to a log no one reads gives the appearance of control without the substance. Assessors ask who receives the alert, how fast it is triaged and what happens when it fires outside working hours. Define a named recipient or queue for each alert class, set an escalation path, and keep records of alerts reviewed and actions taken.

Checks blind to administrator changes

A monitor running with the same privileges as the attacker or a careless administrator can be disabled, reconfigured or fed a new baseline. Assessors test whether an actor with administrative rights can alter both the data and the record of its integrity. Run the integrity agent under separate control, protect its configuration and baseline, and forward alerts to a store that the monitored host cannot rewrite.

No path for reporting corruption

Point (2)(f) requires the product to report on corruptions, and a detected problem that stays on the device has no route to the manufacturer or user. Define how a corruption event is reported to the operator, what information it carries and who in the manufacturer's organization owns the follow-up. Test the path end to end before release, including a case where the product cannot reach the network.

Who does what: your team, an implementation partner and the auditor

Your organization owns the product, its cybersecurity risk assessment and the decisions about which integrity protections the product needs. Point (2)(f) asks you to protect stored, transmitted and processed data, commands, programs and configuration against unauthorized manipulation and to report corruptions, so your team must decide what counts as protected material for each product and which corruptions must be reported and to whom. Those decisions belong in the risk assessment and the technical documentation, signed off by people accountable for the product.

Scope decisions: Define which files, configuration items, boot components, firmware and data stores fall under integrity protection, and record the reasoning.
Risk assessment ownership: Link each integrity decision to the threats it addresses and keep the assessment current through the support period.
Alert handling: Decide who triages integrity alerts, what constitutes a reportable corruption and how it reaches the reporting process.
Evidence custody: Keep baselines, alert records, change approvals and test results under your own control, not only in a partner's environment.
Vendor and component questions: Confirm with suppliers how their components protect their own integrity and which obligations pass to you.

Before engaging anyone, confirm internally who signs the (2)(f) position and who answers for it to an assessor.

What buyers ask before bringing in help for point (2)(f)

What does outside help for point (2)(f) cost, and what drives the price?

Outside help for point (2)(f) is priced from a written scope, so the main cost drivers are the number of products, the number of distinct data flows and configuration sets, the boot and update chain, and how much evidence already exists. No researched cost figure is available for this work, so ask any provider for a fixed-scope quote that lists deliverables. DeployOpen plans and implements integrity controls in the client's own infrastructure and prepares the evidence, and it sets its quote from that written scope. The one-time costs usually cover the risk-based design, tooling setup, baselines and documentation. Recurring costs cover monitoring, reviewing alerts, re-baselining after authorized changes and retesting after upgrades. Ask the provider to separate these two groups in the quote.

How long does it take to prepare integrity evidence for (2)(f)?

The duration depends on how many components need integrity controls and how much of the system is already instrumented, and no researched duration is available to quote. Preparation typically includes defining what must be protected, establishing baselines, configuring alerting and recording how corruption is reported. Your engineering team must supply system architecture details, change-control records, access to test environments and a named owner for the configuration baseline. Confirm with any provider how long each phase will take and which of those phases depend on your team's availability.

Can one engineer handle the (2)(f) work in-house?

One engineer can often handle the design and the first deployment for a single product line, but the work usually spans security, platform and release engineering. The engineer needs working knowledge of the product's boot process, update mechanism, configuration files and logging pipeline. Plan for a second reviewer so that baseline changes are approved by someone other than the person who made them. If your team cannot cover this skill set, a fixed-scope engagement can fill the gap, with ownership of controls and evidence staying with your organization.

Can open-source tools produce the evidence for (2)(f)?

Open-source tools can produce much of the evidence an assessor will want, but none of them satisfies point (2)(f) on its own. Wazuh (GPL-2.0-only) file integrity monitoring records a baseline of checksums and attributes for monitored files and directories and alerts on creation, modification or deletion, with details on how, when and by whom the change was made. Bareos (AGPL-3.0-only) Verify jobs compare files against previously cataloged attributes, which supports detection after a break-in. For certificates and secrets, FreeIPA's integrated Dogtag-based certificate authority and the OpenBao PKI secrets engine can issue and manage X.509 certificates. Confirm each tool's fit against your product's architecture and the license terms before relying on it. Review the Wazuh file integrity documentation to see what alerts contain.

How does (2)(f) connect to the Article 13(2) risk assessment and Part II updates?

The Article 13(2) cybersecurity risk assessment decides which integrity controls apply, how strong they must be and what residual risk remains. Point (2)(f) requires protection against unauthorized manipulation of data, commands, programs and configuration, and reporting on corruptions, so the risk assessment should name the assets that need protection and the threats to them. Annex I Part II point (7) separately requires secure update distribution so that vulnerabilities are fixed or mitigated in a timely manner. Integrity controls on update packages and boot components therefore feed both requirements. Keep the risk assessment current through the support period, and record changes to baselines alongside it.

What will an assessor ask for to test point (2)(f)?

An assessor will normally ask which assets are protected, how the protection was designed from the risk assessment, and how you know it works. Expect requests for the list of protected data, commands, programs and configuration, the baseline records, sample alerts showing detection of an unauthorized change, records of how authorized changes are approved and re-baselined, and the procedure for reporting corruption. Assessors also check that the people who run the controls are not the only people who approve baseline changes. Confirm with your conformity assessment body which evidence format and sampling approach it expects before you build the evidence pack. Only an independent notified body or market surveillance authority can judge conformity; no implementation partner issues that outcome.

Who owns the (2)(f) controls, and what does an implementation partner do?

Your organization owns the controls, the risk decisions and the declaration of conformity. An implementation partner plans, configures, documents and tests the integrity mechanisms and assembles the evidence, but it does not decide what counts as conformity. Ask any provider to state in writing which deliverables it will hand over, who keeps the baseline records after the engagement ends and who runs monitoring afterward. Independent assessment bodies issue any report or certification.

How DeployOpen scopes and prepares integrity evidence

DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure, so integrity controls for Annex I Part I (2)(f) can be set up, tested and recorded where the data and configuration actually live. The organization keeps ownership of its risk assessment and product decisions, and an independent assessor or notified body issues any conformity outcome.

How we scope

Scope starts from the manufacturer's documented risk assessment and the product's stored, transmitted and processed data, commands, programs and configuration.
Engagements are fixed-scope, with the integrity boundaries, monitored paths and reporting duties agreed in writing before work starts.
The written scope names which boot, firmware, configuration and update artifacts are in or out, so the evidence trail matches the product claim.

How we build

We deploy file integrity monitoring such as Wazuh to baseline checksums and attributes of agreed files and directories, then alert on unexpected change.
We configure scheduled Bareos verify jobs against cataloged attributes so backup restores can be checked for modification after an incident.
We set up certificate and secrets issuance, for example FreeIPA and OpenBao PKI, so trust material is issued and rotated under recorded control.

How we hand over

Deliverables include the baseline definitions, alert rules, verify job configurations and a record of who can change monitored paths.
Test records show deliberate modifications being detected, with logs that capture how, when and by which account a file changed.
Documentation is written so the manufacturer's technical file and assessor can trace each integrity control back to the risk assessment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so monitored baselines stay current after each approved update.
Changes to monitored paths, such as new firmware or configuration releases, are reviewed and the baseline is re-recorded under change control.
Before any assessment, confirm with your assessor which evidence formats and retention periods they will accept for integrity records.

Annex I Part I (2)(f) Integrity of data and configuration