EU Cyber Resilience Act Reporting: What Document Platform Buyers Should Ask

Regulatory information checked: November 6, 2026.

The EU Cyber Resilience Act has moved from a future product-security requirement to an active reporting obligation. Since September 11, 2026, manufacturers of in-scope products with digital elements must report actively exploited vulnerabilities and severe security incidents through the EU's Single Reporting Platform.

For document platform buyers, the practical question is not simply whether a supplier says its product is secure. It is whether the supplier and customer can recognize a reportable event, preserve the necessary evidence, assign responsibility, and act within a short regulatory clock.

This article is not legal advice. It is a procurement and architecture checklist for organizations assessing software that will store, process, search, and route sensitive documents.

First establish scope and legal roles

The CRA covers connected software and hardware products made available on the EU market, subject to its exclusions. Associated remote processing is included when designed by or under the manufacturer's responsibility and necessary for a product function. See the Commission's scope summary.

A manufacturer supplies a product under its own name or trademark; a customer merely operating it does not thereby become its manufacturer. Resupplying or substantially modifying software can change that assessment. Customer-managed versus vendor-managed deployment allocates operational work; account ownership does not determine CRA applicability.

Under the Commission's open-source guidance, noncommercial free and open-source software is excluded; commercial supply can be covered. Open-source stewards have a separate regime. Assess FormKiQ Core's distribution and monetisation context separately from commercial Business Solutions. An open-source licence alone does not settle scope or reporting duties.

What changed in September 2026?

CRA Article 14 sets separate reporting clocks for manufacturers. Notifications go to the coordinating CSIRT and ENISA via the Single Reporting Platform.

Early warnings and notifications must be made without undue delay; the hours above are outer limits. Final reports are required unless the relevant information was already supplied. Investigation completion does not postpone the incident deadline.

The full CRA applies from December 11, 2027, but organizations should not treat reporting as a 2027 project. The reporting process is already operational, and it depends on capabilities that take time to establish:

• an inventory of supported products, versions, components, and dependencies;
• a documented vulnerability intake and triage process;
• clear criteria for identifying active exploitation and severe incidents;
• an evidence trail showing when the supplier became aware;
• named decision-makers and backups for time-sensitive reporting;
• a communication path between the software manufacturer, operator, customer, and relevant security teams.

Why document platforms deserve specific scrutiny

A document platform often sits at the intersection of untrusted files, sensitive records, identity systems, search indexes, AI services, and downstream business applications. It may ingest files from email, SFTP, scanners, cloud storage, collaboration tools, or public portals. It may also generate links, extract text, call eSignature services, and publish events to other systems.

That makes the platform both a repository and a processing surface. A weakness in upload handling, authorization, document rendering, identity integration, or a third-party component can affect more than one file. Buyers should therefore ask how the supplier separates four questions:

1. Is the product vulnerable? Determine affected versions, configurations, and components.
2. Is the vulnerability being actively exploited? Distinguish a theoretical weakness from observed exploitation.
3. Has a customer environment been affected? Use account-level logs and telemetry to determine actual impact.
4. Who owns each response action? Assign product remediation, operational containment, customer notification, and regulatory reporting.

Seven questions to add to procurement and renewal reviews

Deployment boundaries change the investigation

A shared application can still be operated securely, but incident scoping begins inside infrastructure used by multiple customers. A segregated deployment provides a different evidence boundary. Logs, storage, keys, queues, and service metrics can be examined for one environment without first separating that customer's activity from a shared application plane.

FormKiQ is designed to run in a segregated AWS account, either customer-managed or vendor-managed. Documents are stored in Amazon S3, metadata in Amazon DynamoDB, with processing boundaries determined by the configured services and integrations. This does not remove product-security obligations. It does make the operational boundary concrete, which can improve containment, evidence collection, and customer-specific impact analysis.

The security and governance guidance separates three evidence boundaries:

• Primary storage: inspect S3 and DynamoDB resource locations, replication and backup configuration, IAM/KMS policies, and configured audit logs. Verify logging coverage and retention before relying on it.
• Bedrock inference: AWS permissions govern requests, while the selected model and inference profile govern processing geography. Retain model/profile identifiers, routing configuration, and available request logs; an account's storage region alone does not prove inference residency.
• External integrations: signature, credit, and other connected services have separate processing boundaries. Collect outbound request identifiers, returned evidence, provider logs where available, and contractual location and retention terms. Deployment logs alone cannot establish what happened inside another provider.

The distinction between product responsibility and environment responsibility should still be documented. FormKiQ may be responsible for a product defect and its remediation, while the account operator may be responsible for monitoring, access configuration, backup operations, and parts of incident containment. The contract and operating model should say who does what before an incident begins.

Apply the checklist to FormKiQ

Public evidence provides a starting point for diligence. It does not establish a CRA compliance claim or an incident-response service level.

Proposed contractual commitments should specify response coverage, escalation times, evidence access and retention, notification timing, and patch delivery responsibilities. Negotiate and record these for the chosen edition and operating model; the public pages above do not by themselves promise these terms.

Example: from detection to reporting and containment

Reporting readiness is an engineering capability

A 24-hour early-warning period leaves little room to invent the process during an incident. Organizations need a rehearsed path from detection to decision. That path should connect vulnerability management, product engineering, customer operations, legal review, and regulatory reporting without making any one person a single point of failure.

For document platforms, useful preparation includes testing file-ingestion controls, reviewing object-level authorization, validating audit coverage, keeping supported versions current, and rehearsing how to identify affected documents or users. The goal is not to promise that incidents will never occur. The goal is to know what happened, limit the impact, communicate accurately, and correct the weakness.

The CRA turns those capabilities into procurement evidence. Buyers should expect specific answers, and suppliers should be prepared to provide them.