iKNSA International
Self-assessment10 to 15 minClient areaContact iKNSA

Guidance by trigger

The triggering event determines the order of the analysis.

A questionnaire, an audit, market entry or the maintenance of several engagements each call for distinct decisions and levels of evidence.

Review situations

A client request exists

Security questionnaireContractual annexAnnounced auditFindings received

A decision needs to be prepared

RenewalEU call for tendersEU market entryProduct security

The role determines the mandate

The supplier examines its own capability. The European client defines the supplier decision it needs to reach.

Self-assess my organisation →Assess a supplier →Search the platform →

Choose an engagement

Meet the deadline. Establish capacity. Sustain commitments.

Start from what needs to be obtained now: an answer, an in-depth review, or a capability tracked over time.

View all engagements
01

Reply

A document and a deadline.

QuestionnaireAnnexAuditAll responses →
02

Prepare

Verify and remediate.

EU exposureClient and technical assessmentEvidence and remediationAll preparations →
03

Maintain

Keep the current commitments.

Continuous assuranceClient assurance officeProduct security cellAll recurring services →

Basis for the conclusions

From the client's requirement to a qualified piece of evidence.

The same trail links Promise, Policy, Practice, Platform, finding, remediation and controlled sharing.

Review the 4P method

Trace

Evidence traceabilityAssurance registerTrust roomContinuous verification

Frameworks and sectors

GDPR and international accessHealth data and HDSNIS2 and the supply chainIndustrial confidentialityAll frameworks →

View deliverables

See fictitious examples to understand the structure and depth of the deliverables.

See examples of deliverables →

Terms of engagement

Responsibilities, information and limits established before the engagement.

Confidentiality, independence, reversibility and traceability of responsibilities structure the conduct of the work.

Review the firm's rules

Trust rules

ConfidentialityIndependenceSecurityReversibility

Working with iKNSA

ExpertiseInternational engagementsRequest an engagementContact

European principals

Have an international supplier assessed under explicit mandate and sharing rules.

Assess a supplier →
Your contextContext not defined
Country of the organisation assessedNot provided
What it providesNot provided
Relationship with the EUNot provided
Home / Product security gap

Product security gap

Product security must operate at every release.

Development, dependencies, SBOM, vulnerabilities, fixes, incidents and support must form a workable, provable process.

What your context changes

Decision to be made

To be addressed first

See the corresponding pathway →

What indicates that you are affected

  • Software or connected product
  • European market or clients
  • Incomplete vulnerability process

What weakens the client relationship

  • Disclosure channel with no process
  • SBOM disconnected from released versions
  • Support promised without engineering capacity
  • Client statements exceeding product evidence
Decision to be obtainedAn assessment of the product security cycle, technical and organisational gaps, followed by a maintainable preparation plan.

The conclusion links the products and versions concerned to the correction, support and communication decisions still open.

Review logic

From the product cycle to the security evidence that must be maintained.

The sequence follows the release cycle so that vulnerability, fix, support and communication remain linked.

01Delimit

Identify products, versions and support periods.

02Review

Link development, dependencies, SBOM and released versions.

03Test

Test vulnerability handling, patching and incident processes.

04Maintain

Keep evidence available throughout the product lifecycle.

Product security cycle

Evidence maintained with every version delivered.

Demonstration example
01DesignThreats and requirements
→
02BuildCode and dependencies
→
03PublishSBOM and version
→
04MaintainVulnerabilities and patches

Items to be gathered

Prepare the file before widening the review.

  • The products, versions, components and support periods concerned
  • The deadline and the associated commercial decision
  • Commitments already communicated to the parties concerned
  • The individuals able to explain how things actually work
  • The available evidence, including where it is partial
  • Exceptions, incidents or remediations already known
ENTRYThe products, versions, components and support periods concerned
VIGILANCEDisclosure channel with no process

SBOM disconnected from released versions

DECISIONAn assessment of the product security cycle, technical and organisational gaps, followed by a maintainable preparation plan.

Indicative timeline

In line with supported versions

Link security decisions to released versions, vulnerabilities, patches and support periods.

Current state

Development cycle, vulnerabilities, dependencies, SBOM, support: what genuinely exists, version by version.

Gaps

What European buyers and the CRA framework expect from a publisher of your size — and what is missing.

Upgrade

Processes set at your scale: disclosure, patches, a maintained SBOM, sustainable support commitments.

Pace

Product security runs with every version shipped — and is proven at every client evaluation.

Consistent intervention

Product security assessment and CRA preparation

Assess the actual capacity to design, maintain, patch and document a product intended for Europe. The products, maintained versions and market dates make it possible to target the lifecycle, components and security decisions to be examined.

Examine the scope of the engagementContact iKNSA →