We already have a security incident procedure. Is that enough?

Incident handling deals with attacks that have happened; vulnerability handling deals with reported weaknesses. Their triggers, time limits and outputs differ. An existing incident process is a good base, but you still need a process and records specific to vulnerabilities.

Do vulnerabilities in older products still under support have to be handled?

Yes. The CRA requires manufacturers to handle vulnerabilities effectively under Annex I, Part II from placing the product on the market and throughout the support period (Article 13(8)); the support period must be at least five years, and its end date, with at least the month and year, must be clearly specified at the time of purchase (Article 13(19)). The Article 14 reporting obligations also cover products placed on the market before 11 December 2027 (Article 69(3)).

Do ISO/IEC 30111 and 29147 have to be done together?

Setting them up as a pair is advisable: the two standards reference each other and their processes connect, so doing them separately leaves audit gaps at the hand-over.

How to choose an ISO/IEC 30111 consultant in Taiwan: eight criteria

Direct answer: the first question to ask an ISO/IEC 30111 consultant is "once a vulnerability report arrives, who verifies it, who sets its severity, who fixes it, and how fast is the fix released?" ISO/IEC 30111 sets out a vendor's internal process after receiving vulnerability information: verification and reproduction, severity rating, root-cause analysis, remediation development and testing, release and follow-up monitoring. Receiving reports from outside and publishing advisories are covered by ISO/IEC 29147. Next, check whether the consultant can connect the process to the SBOM and the security update mechanism, and map it to the EU CRA. Annex I, Part II requires manufacturers to draw up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies (point 1); to address and remediate vulnerabilities without delay, providing security updates separately from functionality updates where technically feasible (point 2); and, once a security update is available, to disseminate it without delay and free of charge unless otherwise agreed for a tailor-made product, with advisory messages telling users what action to take (point 8). The support period must be at least five years (or the expected use time if shorter), and each security update issued during it must remain available for at least 10 years or the rest of the support period, whichever is longer (Article 13(8) and (9)). The CRA itself does not name ISO/IEC 30111; the 2024 standards-mapping analysis by the EU Joint Research Centre (JRC) and ENISA found EN ISO/IEC 30111 to be the most relevant standard for these vulnerability handling requirements, mapping to five of the eight (points 2, 4, 5, 6 and 8), while the SBOM, security testing and review, and secure update distribution have to be covered by other standards or measures.

Five gates in the 30111 handling process

Gate	What has to be decided	Common gap
Intake and verification	Whether the report is valid, whether it can be reproduced, which products and versions are affected	No product and component list, so the impact cannot be determined
Prioritisation	Which criteria set severity and handling time limits	The criteria exist only in individual experience
Remediation	Who is responsible for fixes, workarounds and testing	No one is responsible for old versions and discontinued models
Release	How security updates reach users, and when the advisory is published	Security updates bundled with feature updates
Review	Root-cause analysis and process improvement	The same kind of vulnerability keeps recurring

Eight criteria

Criterion	Question you can ask any consultant
Process and owners	From intake to release, who owns each gate, and what are the time limits?
Prioritisation criteria	What criteria set severity? Will they be adjusted to our product context?
Impact assessment	With several product lines and versions, how do we quickly determine which are affected?
Link to the SBOM	Without an SBOM, how do we know which component's vulnerability affects us?
Delivering security updates	Once fixed, how does the update reach users? What happens to old versions?
Support period	How is the support period set, and how are vulnerabilities handled during it?
Link to incident response and 29147	How do vulnerability handling, security incident handling and outward disclosure divide the work and hand over?
Who leads, and is work subcontracted	Who actually runs the engagement, with what qualifications? Will any of it be subcontracted?

When you may not need a consultant

If your product line is simple, you already have a mature product security team and handling records, and you only need to fill documentation gaps against ISO/IEC 30111, you can start with your own gap analysis.

How Winners Consulting addresses these criteria

What follows is Winners Consulting's own description. Test us with the questions above, just as you test other consultants.

Process and owners: write "who takes the report, who verifies, who rates, who fixes, who releases, and how fast" into an auditable process with time limits
Prioritisation criteria: set prioritisation criteria adjusted to the product context (for example, localised CVSS criteria)
Handling records: set up handling records and time-limit reporting
Link to the SBOM: set up the procedure that connects handling to the SBOM; Winners Consulting's own delivery pipeline generates, signs and monitors SBOMs every day
Link to incident response and 29147: connect to existing incident response (ISO/IEC 27035) and supplier management (ISO/IEC 27036), and document the interface with the 29147 disclosure side
Multiple product lines: design a cross-product mechanism for assessing vulnerability impact
Who leads: vice-president and director-level consultants run the whole engagement; nothing is subcontracted

Compliance needs all three; a consultant's value is integration

CRA, TISAX, ISO 27701 and the AI Act are not single technical problems. They are only complete when process, security technology and legal compliance all hold at the same time. Fix only one and the gaps in the other two surface during audits, incident reporting or customer due diligence, and the work has to be redone.

Dimension	The question it answers	Typical gap when only this part is done
Process (management system)	Who is responsible, what is done, when, where the evidence is, how it improves	Tools are in place but nobody runs them on schedule, so there are no records at audit time
Security technology	How controls are designed and how their effectiveness is verified	Documents are complete but the systems do not actually do what they describe
Legal compliance	Which regulation applies, which role you hold, the deadlines and penalties	Controls are built against the wrong regulation or role, so obligations are not covered

Winners' consulting team covers all three dimensions and plans regulatory scoping, process design and technical controls together, so a single body of evidence serves multiple regulations and customer requirements.