NFR compliance response for a tier-1 European energy operator

Context

An enterprise procurement team at a tier-1 European energy operator had issued a multi-domain non-functional requirement (NFR) catalog as part of pre-contract due diligence for a software vendor relationship. The catalog ran to roughly fifty line items spanning four broad domains:

1. Cyber security — authentication, role-based access control, multi-factor authentication, data classification, encryption in transit and at rest, key management, vulnerability management, penetration testing, incident response, patching, network security, logging and monitoring, access reviews, SIEM integration, data-loss prevention, backup security, secure SDLC, third-party risk, GDPR / privacy, business continuity, security training, compliance reporting.
2. Data architecture — governance, quality, event-driven architecture, retention, lineage, master data management, microservice / loose coupling, API and OpenAPI standards, dual access methods.
3. Technical architecture / application — scalability (horizontal and vertical), island-mode operation, observability.
4. Business continuity / DR — recovery point and time objectives, geo-redundancy, failover testing, backup integrity.

The vendor had a vendor-side architecture, an Azure-native security stack, and a working product. What it needed was a structured response that would survive procurement review — line by line, with evidence — within a fixed window.

Approach

We worked in the structure the procurement team imposed and added the structure they did not.

The compliance register itself ran one row per requirement, columned for: requirement text, compliance status (one of compliant, partial, non-compliant, desirable), justification, source / evidence reference, action required, cost-impact estimate, and timeline. Where existing product capability covered a requirement, the source column linked to the artifact that proved it. Where capability was partial or absent, the action and cost columns made the gap explicit and quantified.

Around the register we added three structural artifacts the original catalog had not asked for:

• A “difficult items” deep-dive. Roughly seven of the line items required more than a register row — typically because they cut across multiple domains, or because the answer depended on customer-side decisions that had not yet been made. Each got its own narrative page.
• A source-verification log. Roughly thirty entries linking specific justifications to specific meetings, emails, or design documents. This converted we comply with X claims into auditable provenance.
• A cost-impact summary. A consolidated view of the cost implications across all partial and non-compliant items, with rough timeline. Procurement teams typically discover this number through painful renegotiation; surfacing it up front shortened the conversation.

We worked across the standard Azure-native security stack — Entra ID, Key Vault, Defender, Purview, Sentinel, Event Hub, Log Analytics — but the methodology is platform-agnostic. The artifact would have looked the same on AWS or GCP equivalents.

What we delivered

• A roughly fifty-line compliance register covering security, data, and architecture domains
• A deep-dive narrative on the seven items that required more than a row
• A thirty-entry source-verification log
• A cost-impact summary with rough timeline
• Explicit identification of five open customer-side clarifications that did not block initial response

Outcome

The vendor entered the procurement review with a structured response that documented compliance, evidence, and gap costs in the same artifact. The difficult items deep-dive answered, in advance, the questions a hostile procurement read would have asked. The cost-impact summary surfaced renegotiation triggers before they became friction.

The five open customer-side clarifications were relayed back to the customer’s architecture team as part of the response, narrowing the next round of questions.

What we did not deliver

A penetration test. A security audit. ISO 27001 documentation. Implementation of any partial-compliance items. The deliverable was structured advisory, not security work.

Engagement shape

Fixed-scope engagement, pre-contract due diligence shape, single principal. Materials produced as a structured workbook in the procurement team’s preferred file format. Confidential throughout; no public materials produced.