Establish the obligation, then choose the measure
Sources reviewed on 27 September 2026. The frameworks discussed here address different subjects: NIS2 covers entities within its statutory scope, the EU GDPR covers personal data processing within its scope, the Cyber Resilience Act covers certain products, and DORA covers the financial sector. IT-Grundschutz and PCI DSS should be considered separately as standards or specific assessment frameworks.
Ask three questions for each web application: which data and services does it protect? Which statutory and contractual requirements actually apply? Which measures and checks demonstrate the necessary effect? An appropriate header can be part of the answer. It does not replace secure application logic, authorisation, maintenance or incident handling.
A typical limitation: a website sends a strict Content Security Policy, yet the application gives logged-in customers access to other customers’ invoices. The header does not solve this authorisation problem. Conversely, a missing optional header does not by itself establish a breach of law without considering functionality, browser rules and risk.
Technical measures and the limits of their evidence
The table places all the technical subjects in this overview in context. It is not a complete mapping to any legal provision. Additional checks must cover the affected workflow, such as login, checkout or an administrative function; a homepage response alone is often insufficient.
On narrow screens, scroll the table sideways.
| Mechanism | Potential technical contribution | What else needs checking |
|---|---|---|
| Content Security Policy | Appropriate enforced directives restrict resources and script execution. | Effective rules, sources, nonces or hashes, and their effect in the browser. Report-Only does not block; a CSP replaces neither fixing vulnerabilities nor complete script management. |
| HSTS | A browser uses HTTPS for a hostname it recognises as an HSTS host. | First contact, policy lifetime, subdomains and, where relevant, actual preload inclusion. HSTS does not itself encrypt data or assess the entire TLS configuration. |
| Cookie security | Depending on the attribute, cookie attributes restrict transmission, script access and certain cross-site uses. | All relevant cookies across login, role and purchase workflows, server-side session rules and CSRF protection. A securely configured cookie establishes neither consent nor another legal basis. |
| X-Frame-Options | Supports restrictions on embedding in frames. | Effective embedding rules, including CSP frame-ancestors, required integrations and target browsers. The presence of a header is no general guarantee against clickjacking or of application security. |
| Referrer-Policy | Limits the referrer information a browser sends with requests. | The policy and navigation or resource context. It does not remove personal data from URLs, server logs or other transfers. |
| X-Content-Type-Options | nosniff ties script and stylesheet use in particular to appropriate MIME types. | The actual content type and usage context. It is not universal protection for all content or every JSON response. |
| Permissions-Policy | Controls supported browser features for documents and embedded content. | Feature defaults, browser support, embedded documents and any additional user permission required. A missing header does not mean every feature is freely available. |
| CORP, COOP and COEP | Control certain resource uses and relationships between browser documents. | How the policies work together, the secure environment, embedding and actual browser state. Individual headers establish neither complete cross-origin isolation nor comprehensive protection against side channels. |
| Subresource Integrity | Enables integrity checks of suitable included resources against expected hashes. | The actual resource, hash match, cross-origin requirements and change process. Finding an attribute is not a completed hash validation or a complete script inventory. |
| NEL and reporting | Supporting browsers can report certain errors and violations to configured receivers. | Browser support, reports actually received, analysis, privacy and coverage. An endpoint does not demonstrate complete detection of attacks or tampering. |
| security.txt | Publishes contact information for vulnerability reports. | Reachability, responsibility and handling. The file does not replace statutory reporting of a significant incident to an authority. |
| DNSSEC and CAA | DNSSEC enables verification of DNS data origin and integrity; CAA restricts permitted certificate issuers. | The validation chain, effective CAA processing and certificate operations. Neither DNS encryption nor protection against every domain or subdomain takeover follows from these mechanisms. |
| TLS and certificates | TLS protects the transmission channel between the participating endpoints. | Trust verification and the protocols and configurations actually offered by the relevant endpoints. One fetch establishes neither the entire configuration nor endpoint security. |
| Cache-Control | Controls how HTTP caches handle responses. | Public and personalised routes, shared and private caches, and other storage. no-store does not promise complete erasure or confidentiality in every environment. |
| Clear-Site-Data | Requests that supporting browsers delete certain locally stored site data. | The data types affected, browser behaviour and the server-side session and data lifecycle. A header completes neither server-side logout nor all statutory erasure obligations. |
| Advanced headers | Can set further, individually specific browser rules. | The particular mechanism, current support and compatibility with functionality. The collective label creates no obligation to activate every mechanism. |
Technical foundations include CSP Level 3, Sections 3 and 6, HSTS, RFC 6797, Sections 8 and 14.6, Fetch, Sections 3.6–3.7, SRI, Sections 3–5 and HTTP caching, RFC 9111, Section 5.2. A specification and actual browser support are different forms of evidence; the table claims no browser measurements carried out here.
Six frameworks with different scopes
NIS2 in Germany: protecting services and organisations
The BSIG statements below concern Germany. The EU introduction and country guidance help you select the legal context. The Germany section brings together the German assessment path.
The German implementing legislation has generally applied since 6 December 2025. Section 28 BSIG, the entity categories in Annexes 1–2, size calculations and special rules are decisive. A business is not covered merely because it operates a website or supplies a regulated customer. The general threshold for important entities is at least 50 employees or both annual turnover and annual balance sheet total exceeding €10 million, alongside the appropriate entity category and other conditions. Special cases that do not depend on size still need checking. Section 28 BSIG.
Section 30 requires appropriate and effective measures and documentation, but no universal HTTP header list. Registration under Section 33(1) is generally due no later than three months after an entity first or again becomes subject to the rules; Section 34 and transitional rules for critical infrastructure may add requirements. Management is responsible for implementation and oversight under Section 38. NIS2 checklist, Incident reporting.
Cyber Resilience Act: product obligations and phased dates
Regulation (EU) 2024/2847 entered into force on 10 December 2024. Most of its general obligations apply from 11 December 2027; Chapter IV has applied since 11 June 2026. The reporting obligations in Article 14 have applied since 11 September 2026, so they already applied on the review date used here. Entry into force and the start of application must not be treated as the same date. CRA, Article 71.
The CRA concerns products with digital elements made available on the market under the conditions in Article 2, including certain remote data processing solutions necessary for product functions. This does not automatically make every website or any SaaS service a covered product. The manufacturer’s role, relationship to the product and exemptions, such as certain products already governed by sector-specific rules, need assessment in the particular case. Article 14 distinguishes actively exploited vulnerabilities from severe security incidents; receivers and procedures differ from those under Germany’s BSIG. The transitional provisions in Article 69 also expressly extend these reporting duties to relevant existing products. Relying on “not until 2027” can therefore be too late. CRA, Articles 2–3, 14 and 69.
A header finding can help with a product’s technical analysis. It determines neither the product’s CRA classification nor the manufacturer’s fulfilment of its obligations.
DORA: financial entities and their ICT risks
Regulation (EU) 2022/2554 has applied since 17 January 2025. Article 2 lists the financial entities covered and exemptions; Article 9 concerns protection and prevention. Specific classification and reporting procedures apply to incidents. A supplier does not become a financial entity merely by having a bank as a customer. Contractual requirements under Articles 28–30 and the separate designation of critical ICT third-party service providers under Article 31 must be distinguished. DORA, Articles 2, 9, 19, 28–31 and 64.
Headers can contribute to secure configuration. DORA also requires an appropriate organisation of ICT risk management; a public website check confirms neither overall digital operational resilience nor a service provider’s supervisory classification.
EU GDPR: protecting personal data
The EU GDPR has applied since 25 May 2018. Its material and territorial scope follow from Articles 2 and 3. Article 32 requires controllers and processors to provide a level of security appropriate to the risk, including suitable measures for confidentiality, integrity, availability, restoration and regular assessment of effectiveness. Article 25 concerns data protection by design and by default; Article 5(2) and Article 24 concern accountability and demonstrating implementation. GDPR, Articles 2–3, 5, 24–25, 32 and 99.
A Referrer-Policy can limit unnecessary data disclosure, and secure cookies can support sessions. These measures do not resolve the legal basis, transparency obligations, processor arrangements or requirements for international data transfers. A “GDPR-compliant” verdict based on headers is therefore unsustainable.
The fine thresholds must also be matched to the relevant infringement: Article 83(4) provides for up to €10 million or, for an undertaking, 2% of total worldwide annual turnover in the preceding financial year, whichever is higher, for the infringements listed there, including obligations under Articles 25–39. Paragraph 5 specifies up to €20 million or 4% for other infringements. A missing header triggers none of these amounts automatically; Article 83(2) requires assessment of the individual case.
IT-Grundschutz: a specific recommendation within its own assessment framework
The BSI IT-Grundschutz Compendium, 2023 edition, module APP.3.1, requirement A21, recommends appropriate HTTP response headers. It names CSP, HSTS, Content-Type, X-Content-Type-Options and Cache-Control, as well as cookie attributes. The wording is a SHOULD requirement within that module. This provides a concrete technical reference, but no independent, general statutory obligation for every website. BSI Compendium, APP.3.1.A21, module page 5.
For ISO 27001 certification on the basis of IT-Grundschutz, the assessment rules determine the particular procedure. Version 4.8, dated 1 February 2026 and reviewed for the German source, refers to the 2023 edition; the audit’s start date is decisive. A complete set of headers replaces neither this procedure nor the other measures. BSI assessment rules.
PCI DSS: understand the payment integration before listing headers
PCI DSS is an industry standard for protecting payment card data. The active edition reviewed is 4.0.1; its initially future-dated requirements have applied since 31 March 2025. Requirements 6.4.3 and 11.6.1 concern, in particular, authorised payment page scripts with assured integrity and detection of tampering with scripts and security-relevant HTTP headers as received by the customer’s browser. CSP or SRI can contribute; their presence does not demonstrate the complete process. PCI SSC: publication of 4.0.1, PCI SSC: payment page guidance.
The revised SAQ A provides its own validation route: the individual requirements were removed from this questionnaire, not from the standard. The script-related eligibility criterion explained here concerns embedded payment forms, such as iframes; it does not apply in the same way to simple redirects or fully outsourced payment through a payment link. For embedded forms, PCI SSC describes technical protection approaches or the relevant confirmation from the payment service provider when implementation follows that provider’s instructions. Establish the appropriate questionnaire and evidence scope with the organisation receiving your validation, typically the acquirer or payment brand. PCI SSC: SAQ A changes, FAQ 1588, February 2025.
An arbitrary quarterly header scan is no universal assessment interval derived from these requirements and no substitute for the necessary tamper detection. Testing intervals must fit the applicable procedure and risk.
Document technical and organisational measures clearly
TOM is the German abbreviation for technical and organisational measures. The words “CSP present” or “TLS enabled” are insufficient for sound documentation. Connect the protection objective, affected data and workflows, actual implementation, exceptions, testing and operational responsibility. Evidence must claim only what was actually checked.
The following synthetic documentation examples illustrate suitable wording. No production systems were tested for them. They describe possible, verifiable facts; they are not ready-made confirmation for your website.
On narrow screens, scroll the table sideways.
| Measure | Example of a precise entry | What remains outside this evidence |
|---|---|---|
| HTTPS with HSTS | “The fictional customer portal portal.example uses HTTPS. In the assumed test, HSTS and the redirects examined were effective. Subdomains have not yet been fully approved; includeSubDomains is therefore not documented as already secured.” | The complete TLS configuration, other hosts, first contact and actual preload inclusion. |
| CSP | “An enforced CSP is assessed for the fictional order form. Authorised scripts and required exceptions are recorded in the associated inventory. A Report-Only test is recorded separately from the production protection status.” | Complete application security, correct hashes or nonces, and the effect on every relevant user workflow. |
| Session cookies | “The assumed test workflows cover login, role changes and logout. Secure, HttpOnly and the justified SameSite setting are recorded for the session cookies observed; server-side revocation is tested separately.” | Workflows not exercised, other cookies and the lawfulness of their use. |
| Protection against embedding | “The fictional administration portal must not be embedded by other sites. The effective frame-ancestors rule and, where applicable, X-Frame-Options are checked on administrative routes; permitted business integrations are expressly recorded.” | Other routes and all other types of attack. |
| Limiting referrer information | “The selected Referrer-Policy is documented for the fictional portal. Outgoing links and included resources are checked to establish which information is transmitted. Independently of this policy, personal data should not appear in unnecessary URL parameters.” | Server logs, third-party processing and other transmission routes. |
| Resource integrity | “For static resources protected with SRI, the expected hashes, resources actually checked and release process for changes are brought together. Dynamic scripts and scripts not recorded expressly remain outside this partial evidence.” | A complete script inventory, authorisation of every script and continuous tamper detection. |
For your own entries, add the targets, dates, methods and findings actually checked, the responsible role and the justified next assessment. Do not copy an assumed “effective” from an example into your documentation. Where personal data is involved, appropriately limiting stored evidence, access rights and a justified retention purpose also form part of the record.
Use OWASP to inform technical priorities
The OWASP Top 10:2025 lists Security Misconfiguration as A02; this category ranked fifth in the previous edition. A03:2025 addresses Software Supply Chain Failures and covers more than known vulnerabilities in components used. This helps identify assessment questions but creates no statutory ranking and establishes nothing about your application’s actual findings. OWASP A02:2025, OWASP A03:2025.
Do not therefore check only whether headers are set. Also consider secure defaults, unnecessary functionality, version maintenance, authorisation, and the provenance and changes of dependencies. Your risk and the weaknesses actually observed determine which measure comes first.
Frequently asked questions
Which headers must every NIS2 entity set?
Section 30 of Germany’s BSIG does not prescribe a general list for every HTTP response. Selection and implementation depend on the service, risk and any applicable detailed requirements. A technical recommendation from a particular assessment framework must not be presented as a universal statutory obligation without considering that framework’s scope.
Does a missing header mean a fine or personal liability for management?
No. An individual finding does not establish the conditions for either. Section 65 BSIG distinguishes between infringements and maximum penalties, including €10 million or €7 million for certain breaches and turnover-based alternatives where total turnover exceeds €500 million. Separately, Section 38(2) concerns culpably caused damage to the entity itself under the applicable liability rules. Management responsibility and liability.
Do I need every security header for PCI DSS?
PCI DSS does not require a blanket combination of every header. Identify the payment integration, scripts in scope, protection processes and appropriate evidence. The distinction between an iframe and a redirect explained above matters more than a complete header list.
What does a Wolf-Agents result provide?
The Web Security Check can record selected publicly visible response features and findings. It does not inspect every route, login state, cookie or script executed in the customer’s browser. It is not a complete penetration test, continuous monitoring or proof of compliance. Document its results as a limited snapshot and add the checks appropriate to each protection objective.
From a technical finding to a verified measure
Start with a relevant application and a specific risk. Record which browser rule should help, implement it in a controlled way and test the actual workflow, including possible functional failures. Then place the evidence in your security documentation.
Further reading: NIS2 checklist, NIS2 and ISO 27001, Email security and compliance and the web security overview.