A security control gap decision determines whether one stated security requirement can support one offer when the bidder cannot prove the requested control in the offered scope today. Its work product is a `security_control_gap_decision`. The record fixes the procurement, lot, bidder, solution, deployment boundary, data and user context, document versions and observation time. It preserves the requirement, control objective, threat or assurance outcome, required event, requested proof, current implementation, assessment result, remaining gap, remediation or compensating route, residual risk, buyer permission, exact response wording, approvers and expiry. It does not certify a system, perform a penetration test, accept security risk, disclose protected evidence, reinterpret a tender, contact the buyer or authorize submission.
Security matrices invite false certainty. A supplier selects yes because a control exists somewhere in the company, even though the offered service, region or privileged role is outside its scope. Another team selects no because the buyer names a method the service does not use, although the documents allow a demonstrably equivalent outcome. Planned remediation is sometimes described as implemented. A network restriction is called a compensating control without testing whether it protects the same threat. These shortcuts collapse requirement meaning, control scope, operating evidence and commercial authority into one cell. The result may be an avoidable no-bid, a non-compliant tender or a contractual security promise that the service cannot meet.
Decide against the protection outcome and the buyer's words, not against a control label alone. First establish what the requirement governs, when it must be true and whether the tender accepts equivalent means, later remediation or declared exceptions. Then assess the offered environment as it will be delivered. A positive decision needs one of three evidenced paths: the current control already meets the requirement, approved remediation will be implemented and tested by the permitted event, or a validated compensating control provides comparable protection and the procurement allows that route. Risk acceptance inside the supplier does not change the buyer's requirement. An agent may assemble and test the record, but named security and commercial authorities decide whether the offer proceeds.
Requirement meaning
Read the security requirement as an offer condition
Start with the current procurement documents, not the security team's control catalog. Read the clause beside definitions, response instructions, evaluation rules, implementation schedule, evidence request and draft contract. The same sentence can operate as a condition of participation, a pass or fail technical specification, a scored assurance feature, a milestone due before service, or a continuing contractual duty. Capture the consequence stated for failure. Also separate the control event from the evidence event. A control may need to operate at service commencement while a design and implementation plan are evaluated at tender submission.
Preserve the buyer's parameters. “Multi-factor authentication” is incomplete if the pack also names privileged roles, hardware-bound credentials, phishing resistance, recovery, enrolment, session reauthentication and the first day of administrator access. “Encryption at rest” may specify covered data, key ownership, rotation, separation of duties, region and deletion. A broad label lets the bidder compare unlike systems and return a false match. The decision record should expose the parameter mismatch without publishing the supplier's sensitive design.
Equivalent solutions require a source. Article 42 of Directive 2014/24/EU contains routes for proving that proposed solutions meet referenced specifications or performance and functional requirements in an equivalent manner. Section 56 of the UK Procurement Act 2023 and current Cabinet Office guidance address performance or functional requirements and equivalent standards in defined circumstances. These provisions do not convert every named security method into an optional preference. Apply the exact procurement documents and governing context. If the route is unclear, return `clarification_required` or `legal_review_required` rather than inventing permission.
| Requirement role | Question for the bidder | Unsafe shortcut |
|---|---|---|
| Participation condition | Must the bidder or relied-on entity meet it now? | Assuming later remediation is allowed |
| Pass or fail specification | What exact offered state must the answer commit to? | Answering yes for a planned control |
| Scored criterion | Which evidenced strength earns credit? | Treating a weak score as disqualification |
| Implementation milestone | What must be built, assessed and accepted by which event? | Using the bid deadline as the control deadline |
| Contract duty | What continuing operation, evidence and remedy will bind? | Ignoring downstream warranty and service terms |
| Due diligence request | What can be disclosed accurately and safely? | Confusing disclosure with buyer acceptance |
Current state
Prove the control where the proposed service will run
Fix the offered environment before inspecting evidence. Name the legal entity, service and edition, hosting and tenancy model, region, relevant data classes, integrations, privileged roles, customer responsibilities, subprocessors and service phase. A control can be well designed and effective for the corporate network yet irrelevant to a hosted product. It can protect production but not support tooling, or one region but not another. An enterprise audit report helps only to the extent that its period, system boundary, control wording and exceptions support the specific claim.
Test four different questions. Design evidence shows how the control is meant to work. Implementation evidence shows that the mechanism exists in the fixed scope. Operating evidence shows that it ran over the relevant period. Assessment evidence tests whether it met the stated objective. NIST SP 800-53A provides a methodology and customizable procedures for assessing security and privacy controls; it is not a certificate of this supplier or an automatic procurement rule. Use the organization's applicable assessment method, but retain the object, method, assessor, date, result, limitations and unresolved findings.
Classify the state without smoothing over bad news. `implemented_verified` requires scope-matched and current evidence. `implemented_scope_mismatch` means the mechanism exists but not where the offer needs it. `partially_implemented` preserves an incomplete parameter or population. `not_implemented` is direct. `planned_unapproved` records intent without authority. `remediation_approved` identifies a governed future path. `compensating_candidate` is an untested alternative. `compensating_validated` requires comparable-protection reasoning, assessment and approval. `evidence_missing` prevents a positive claim even when an owner believes the control operates.
| Evidence layer | Record | What it cannot prove alone |
|---|---|---|
| Design | Policy, architecture decision and control owner | Deployment or operation |
| Implementation | Configuration or deployment evidence for the fixed scope | Sustained operation |
| Operation | Dated logs, reviews or samples across the relevant period | Effectiveness against the objective |
| Assessment | Object, method, assessor, test date, result and findings | Future performance after a material change |
| External assurance | Report scope, period, criteria, opinion and exceptions | Controls or environments outside that boundary |
Satisfaction routes
Keep remediation, compensation and buyer exception separate
Remediation changes the control state. Model it from the required outcome backwards through design approval, implementation, secure configuration, migration, documentation, training, assessment, finding closure, production release and buyer acceptance where applicable. Each milestone needs an owner, predecessors, evidence, earliest and latest supported finish, adverse branch and stop date. A ticket or target quarter is not an approved remediation path. Nor does an internal test close the route when the tender requires independent evidence or buyer acceptance.
A compensating control protects the same objective by another means. NIST defines a compensating security control as a management, operational or technical safeguard used in place of a recommended baseline control that provides equivalent or comparable protection. That definition is useful discipline, not universal permission for a tender. State why the requested control cannot be used, map the alternative to the same assets and threat, identify differences and new dependencies, test effectiveness, record residual risk, and obtain the organization's required approval. Rate limiting does not replace phishing-resistant authentication. A manual review does not automatically replace immutable logging. Similar effort is not comparable protection.
A buyer exception is different again. The supplier asks the buyer to accept a departure, limitation or later state under the permitted procedure. Internal risk acceptance only says the supplier's authorized person accepts its own residual exposure; it cannot amend a mandatory buyer requirement. Likewise, procurement equivalence may concern a standard or an outcome and may require proof in the tender. Preserve whether variants, deviations or clarification are allowed, the required location for disclosure and the authority to contact the buyer. Never bury an exception behind an unconditional compliance response.
| Route | Minimum proof | Decision boundary |
|---|---|---|
| Current control | Scope-matched operation and assessment evidence | No unresolved parameter gap |
| Approved remediation | Authorized plan, resources, critical path and completion test | Must finish by the tender-permitted event |
| Compensating control | Comparable-protection rationale, assessment and residual-risk approval | Tender must permit the different means |
| Equivalent solution | Exact legal and tender basis plus proof of equivalent outcome | Not a general right to rewrite requirements |
| Buyer exception | Allowed disclosure route and explicit buyer acceptance | Internal approval cannot substitute |
| No bid | Material unmet requirement with no authorized route | Do not convert commercial appetite into compliance |
Decision and wording
Approve the bid and the words as one controlled decision
Return a controlled result instead of a green, amber or red impression. Use `bid_supported_by_current_control` when current evidence covers every required parameter. Use `bid_supported_by_approved_remediation` only when later satisfaction is permitted and the approved path reaches assessed completion in time. Use `bid_supported_by_validated_compensating_control` when comparable protection and the procurement route are both proved. `security_review_required`, `clarification_required` and `buyer_exception_required` keep unresolved work visible. `no_bid_security_gap`, `source_conflict`, `legal_review_required` and `authority_missing` stop unsupported progression.
Attach the exact proposed response. “Yes” must refer to the offered scope and current or expressly permitted future state. If the buyer requires a prescribed matrix, place any explanation or exception where the instructions say it will be evaluated. Keep approved public wording separate from restricted evidence. A buyer may need a control description, assessment summary or certificate, but rarely needs raw logs, a vulnerability report, credentials or a detailed internal diagram. Record recipient, purpose, confidentiality route, permitted detail and disclosure approver for every protected artifact.
Reconcile the conclusion across the whole offer. Remediation can change implementation effort, price, service commencement, acceptance criteria and remedies. A compensating control can add manual work, monitoring, third-party dependency or customer responsibility. An exception can affect scoring or contract negotiation. Compare the security questionnaire, technical response, data schedules, implementation plan, service levels, pricing, assumptions and draft contract. Security authority owns the control and residual-risk judgment. Product and delivery owners confirm feasibility. Commercial authority accepts cost and pursuit exposure. Legal reviewers address compliance wording and contract effect.
| Field group | Required contents | Agent use |
|---|---|---|
| Identity | Procedure, lot, bidder, offer and environment fingerprint | Prevents evidence transfer across scopes |
| Requirement | Clause, version, parameters, role, event and requested proof | Keeps the buyer meaning inspectable |
| Control state | Implementation class, evidence, assessment and contrary facts | Separates belief from proof |
| Gap route | Remediation, compensation, equivalence or exception basis | Tests only the path actually proposed |
| Decision | Result state, rationale, wording, approvers and next action | Supports bounded recommendation |
| Expiry | Amendment, failed test, delayed plan, scope or contract change | Forces re-evaluation before reuse |
Worked case and agent contract
Example: customer-managed keys are required at service start
A fictional public health authority asks for customer-managed encryption keys for clinical records from the first day of service. The pass or fail matrix asks whether the proposed solution will meet the requirement. The technical schedule defines customer control to include key creation in an authority-controlled account, revocation without supplier action, annual rotation and separation between production and backup keys. Tenders close on 22 October 2026 and service starts on 1 July 2027. These facts are invented and do not describe an active procurement or Zephior's infrastructure.
The offered service currently encrypts the relevant data with provider-managed keys. A customer-key feature has approved design but no committed release, hardware security module integration test, backup-key rotation test or operational runbook. A dedicated tenant and provider-managed key reduce shared exposure, but they do not give the authority the creation and revocation control specified in the tender. They are not recorded as comparable protection. The latest adverse path also passes service commencement. The decision is `security_review_required`, followed by `no_bid_security_gap` unless approved remediation reaches the defined tests in time or the buyer expressly accepts another route.
The machine record contains the procedure and lot, source versions, offer fingerprint, data and key scope, requirement parameters, evidence event, control state, protected evidence references, gap class, remediation graph, alternative-control analysis, tender permission, residual risk, proposed wording, cross-offer effects, decision state, approvers, next authorized action and expiry triggers. An agent may locate clauses, compare approved control summaries, detect a scope mismatch, calculate dates, test answer consistency and draft an internal decision or an authorized clarification. It must stop before accessing secrets, probing systems, accepting risk, changing controls, exposing weaknesses, contacting the buyer, promising remediation or submitting the tender.
What good looks like
Useful outcomes from bid with security control gaps
- One procurement, lot, bidder configuration, offer architecture, deployment scope and checked time define the decision.
- The exact security clause, response instruction, evaluation treatment, proof request and required event are source anchored.
- The control objective and protected assets, identities, data flows, threats and operating conditions are stated without exposing sensitive detail.
- Current implementation is classified separately for design, deployment, operation and assessed effectiveness.
- A scope mismatch is visible when a control covers another product, entity, tenant, region, environment or user group.
- Remediation carries approved scope, owners, dependencies, test evidence, earliest and latest finish, and an adverse branch.
- A compensating control is accepted only after comparable protection is reasoned, assessed and approved for the exact scope.
- Buyer permission for equivalence, deviation, clarification or later satisfaction is proved rather than assumed.
- The security conclusion is reconciled with price, implementation, service levels, contract language and every related answer.
- Agents receive an inspectable result, allowed next action and stop conditions without receiving confidential architecture or vulnerability data.
Operating model
How to run the work
- 01
Freeze the offer boundary
Record the authority, procedure, lot, bidder, offered service, deployment model, data classes, privileged roles, relevant third parties, source versions and checked time.
- 02
Parse the security requirement
Preserve the clause, defined terms, mandatory or scored treatment, requested evidence, applicable scope and the event when the control must operate.
- 03
Name the protection objective
Describe the asset, threat, security property, control parameters and assurance result the buyer is seeking before comparing implementations.
- 04
Verify the current control
Inspect design, configured scope, operating records and assessment evidence for the offered environment; retain date, assessor, limitations and contrary evidence.
- 05
Classify the remaining gap
Separate absent implementation, partial operation, scope mismatch, weak evidence, failed test, unapproved plan and external dependency.
- 06
Test each lawful route
Evaluate current compliance, approved remediation, comparable compensating protection, permitted equivalent solution, clarification and buyer exception as distinct paths.
- 07
Reconcile risk and offer terms
Carry the result into solution scope, implementation, price, acceptance, service levels, warranties, liability, evidence delivery and every related response.
- 08
Approve the exact statement
Route the proposed answer and its evidence boundary to named security, product, delivery, commercial and legal authorities appropriate to the commitment.
- 09
Expire on material change
Reopen the decision after an amendment, architecture change, failed assessment, delayed remediation, changed data flow, supplier change or altered contract term.
Evaluation
Questions that change the decision
- Which document and clause control the security requirement for this lot and offer?
- Is the item a participation condition, pass or fail specification, scored criterion, implementation milestone, contract term or due-diligence request?
- When must the control operate, and when must its evidence be supplied?
- What protection outcome, threat and control parameters sit behind the requested label or method?
- Which legal entity, product, environment, region, tenant, data flow and user roles are inside the control evidence?
- Does current evidence prove implementation, operation and effectiveness, or only a policy or design?
- Can approved remediation finish and pass the defined assessment before the permitted event under an adverse schedule?
- Does a proposed compensating control address the same objective with comparable protection, and who assessed that claim?
- Do the tender documents permit equivalence, a variant, a stated deviation, later satisfaction or a clarification?
- What residual risk, cost, service or contract consequence remains, and who can accept it?
- Which exact external words are supportable now, and which change invalidates them?
Failure modes
Where teams lose control
A corporate control is attributed to an offered service that is outside its assessed scope.
A written policy is mistaken for an implemented and operating technical control.
An old test result is reused after the architecture, data flow or privileged roles changed.
A future remediation ticket is described as present compliance or as a guaranteed completion date.
A convenient workaround receives the compensating-control label without an objective, equivalence rationale or effectiveness test.
Internal risk acceptance is treated as permission to depart from an external tender requirement.
An equivalence rule for standards is applied to an exact mandatory method without checking its legal and tender context.
A conditional explanation is hidden in an annex while the required response field says yes without qualification.
Security evidence discloses architecture, exploitable weakness, customer data, credentials or protected assessment detail beyond need.
The technical answer conflicts with the security schedule, implementation plan, service levels, pricing or contract terms.
An agent accepts risk, contacts the buyer, commits remediation or submits without the required human authority.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- security requirements with a fixed source, control objective, offered scope and required event
- current-control claims supported by recent scope-matched operating and assessment evidence
- identified gaps classified by implementation, scope, operation, effectiveness or evidence weakness
- remediation paths with approved resources, dependency graph, adverse date and completion test
- compensating-control claims with comparable-protection rationale, assessment and named approval
- equivalent or exception routes supported by an exact tender or legal basis
- positive bid decisions reconciled across security, technical, delivery, commercial and contract records
- conditional decisions reopened before their evidence or decision expiry
- protected evidence disclosures reviewed for necessity and recipient authorization
- unsupported security claims, concealed deviations, unauthorized risk acceptances and submissions; target zero
Questions
Common questions
Can we answer yes if remediation will finish before go-live?
Only when the tender permits the control to be completed later, the approved path reaches implementation and the required assessment before that event, the adverse schedule remains viable, and authorized reviewers approve the exact response.
Is any workaround a compensating control?
No. The alternative must address the same protection objective, provide comparable protection in the fixed scope, be assessed, preserve its residual risk and dependencies, and follow both internal authority and the tender's permitted route.
Does internal risk acceptance make the bid compliant?
No. Internal acceptance governs the supplier's own risk. It does not change a buyer requirement, authorize an exception or prove that the buyer will accept a different control.
Can a security certificate close the control gap?
Only if its exact scope, period, criteria and result support the specific requirement. A certificate can be relevant evidence, but it does not prove every control parameter or every offered environment.
What may an AI agent decide?
It may assemble a cited, scope-bound recommendation and abstain when evidence or authority is missing. Named humans must approve risk, security claims, remediation commitments, protected disclosure, buyer contact and submission.
Sources
Primary references
- SP 800-53A Revision 5, assessing security and privacy controls National Institute of Standards and Technology
- NIST glossary definition of compensating security control National Institute of Standards and Technology
- Directive 2014/24/EU, consolidated text, Articles 42, 44 and 56 EUR-Lex
- Procurement Act 2023, section 56, technical specifications UK Legislation
- Guidance on technical specifications, updated 13 July 2026 UK Cabinet Office
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.