Japan is preparing a new cybersecurity framework that could significantly change how companies communicate security expectations throughout their supply chains.
It is called the Supply Chain Security Evaluation System, or SCS.
The basic problem SCS is trying to solve is easy to understand.
A large company may depend on hundreds or thousands of suppliers, subcontractors, IT providers, cloud services, maintenance companies and other business partners.
The buyer wants to know:
“Does this supplier have appropriate cybersecurity measures?”
But that can be difficult to determine from outside the organization.
Meanwhile, the supplier may receive:
one questionnaire from Customer A,
another from Customer B,
a different checklist from Customer C,
and still another set of security requirements from Customer D.
The result can be significant administrative burden without necessarily creating a clear, common understanding of security.
Japan’s SCS Evaluation System is intended to address both sides of that problem.
Its purpose is to provide a common framework for evaluating and communicating cybersecurity measures across supply chains.
But there are several important things businesses need to understand before reacting to it.
SCS is voluntary. It is not a law requiring every Japanese company to obtain a star rating.
It is also not intended to be a ranking competition between companies.
And obtaining a star does not require purchasing one specific cybersecurity product.
The real question is:
How can buyers and suppliers use SCS to make cybersecurity expectations clearer, more consistent and more practical?
This article explains what we currently know about ★3 and ★4, what companies can start preparing now, and what SCS does—and does not—mean for business relationships.
What is the SCS Evaluation System?
The formal Japanese name is:
サプライチェーン強化に向けたセキュリティ対策評価制度
or:
Supply Chain Security Evaluation System — SCS
The framework was published in March 2026 by Japan’s Ministry of Economy, Trade and Industry (METI) and the National Cybersecurity Office.
The system is operated by the Information-technology Promotion Agency, Japan (IPA), under government supervision.
Its purpose is to:
- define cybersecurity measures appropriate to different levels of supply-chain importance;
- evaluate whether organizations have implemented those measures;
- make implementation status easier for business partners to understand;
- reduce the burden created by many different customer-specific security questionnaires;
- and strengthen cybersecurity across supply chains.
The SCS system primarily applies to the IT infrastructure of organizations participating in supply chains, including IT infrastructure operated in cloud environments.
Manufacturing-control environments and other OT systems that do not generally form part of the relevant IT infrastructure are not directly covered in the same way and may instead require other sector-specific frameworks or guidance.
That distinction is important.
SCS is a supply-chain cybersecurity evaluation system.
It is not intended to replace every other cybersecurity standard or industry-specific security framework.
Official reference: IPA — SCS detailed information · METI / NCO — March 2026 SCS framework (IPA-hosted PDF)
When will SCS begin?
As of October 2026, IPA states that operation of ★3 and ★4 is planned to begin around:
March 2027.
The implementation infrastructure is already being built.
On 18 September 2026, IPA began accepting applications from organizations that want to become:
- ★4 evaluation bodies;
- technical-verification providers;
- and SCS training providers.
The first designated evaluation bodies are currently expected to be published around the end of December 2026.
Registered SCS security experts are expected to begin being published around January 2027.
IPA published an SCS fee schedule on 18 September 2026. Registration fees are separate from expert-confirmation, evaluation and technical-verification charges. Some company application procedures and supporting guides are still being detailed and published.
Because the framework is actively moving toward operation, companies considering SCS should always confirm the latest IPA information before making an application or commercial commitment.
The current provider-role application deadline is 26 October 2026 at 17:00 Japan time. This is a provider designation deadline, not a deadline for companies to obtain ★3 or ★4.
Official reference: IPA — SCS FAQ · IPA — Provider designation applications · IPA — Published SCS fee schedule (PDF)
★3 and ★4 do not mean “three stars = bad, four stars = good”
This is one of the most important points.
SCS is not intended to operate like a hotel rating.
The star levels represent different expected levels of cybersecurity measures based on supply-chain risk and importance.
METI explicitly states that the system is intended to visualize implementation of cybersecurity measures, not to create a competitive ranking between companies.
The appropriate level therefore depends on the business relationship.
A supplier handling low-risk services may not require the same level of security as:
a critical IT provider,
a supplier holding highly confidential information,
a company whose failure could interrupt a major production process,
or a provider directly connected to important enterprise systems.
The useful question is therefore not:
“Which star is better?”
It is:
“Which level is appropriate for the risk created by this business relationship?”
Official reference: METI — SCS policy and FAQ
What does ★3 mean?
★3 is intended as a cybersecurity level capable of addressing general, widely recognized cyber threats.
The framework describes it as the type of security baseline that supply-chain companies should implement at minimum.
It focuses heavily on fundamental organizational and technical security measures.
Examples include areas such as:
- defining cybersecurity responsibility;
- establishing security policies;
- understanding information assets and networks;
- managing external information services;
- managing user and administrator accounts;
- controlling access;
- protecting network boundaries;
- applying updates;
- malware protection;
- monitoring networks and data;
- establishing incident-response procedures;
- and preparing for recovery.
★3 currently contains 26 requirements.
But ★3 is not simply a checklist that a company completes alone and then awards itself a star.
The evaluation model is:
Expert-confirmed self-assessment
The organization first evaluates itself against the ★3 requirements and evaluation criteria.
An eligible SCS security expert then reviews the organization’s evaluation and supporting information.
The expert may provide advice or require corrections to the evaluation.
Once the expert agrees with the final self-assessment, the expert signs it.
Management must also make the required self-conformity declaration.
The organization then submits the assessment to the SCS administration.
If the application is accepted, the result is registered and publicly listed.
The current framework gives ★3 a validity period of one year.
To maintain it, the organization is expected to review compliance again annually with the required expert confirmation.
Official reference: IPA — ★3 / ★4 requirements and evaluation criteria
What does ★4 mean?
★4 represents a stronger and broader level of cybersecurity.
It is intended for organizations where:
a disruption could have significant consequences for the supply chain;
important customer systems or information could be affected;
or the organization’s role requires stronger supply-chain resilience.
★4 moves beyond basic protection against initial compromise.
The framework includes areas such as:
- stronger governance;
- management reporting and improvement;
- understanding security at important suppliers;
- defining responsibilities with business partners;
- vulnerability-management processes;
- stronger protection of important information;
- logging and analysis;
- network segmentation;
- controls against malicious outbound communication;
- faster detection of abnormal activity;
- and more developed recovery planning.
★4 currently contains 43 requirements.
It includes the requirements of the lower level rather than operating as a completely separate checklist.
However:
A company does not need to obtain ★3 before applying for ★4.
That is explicitly clarified in the official framework.
Official reference: IPA — ★3 / ★4 requirements and evaluation criteria
★4 requires third-party evaluation
The most important procedural difference between ★3 and ★4 is how the security measures are evaluated.
★3 uses:
expert-confirmed self-assessment.
★4 uses:
third-party assessment.
An organization seeking ★4 first performs its own assessment.
It then engages a designated SCS evaluation body.
The evaluation body reviews the organization against the ★4 requirements.
The ★4 process includes:
- document review;
- on-site assessment;
- and technical verification.
Technical verification can be performed by the evaluation body itself when appropriately designated or by another designated technical-verification provider working with the evaluation body.
The evaluation body then provides an evaluation report.
The organization uses the result to apply for ★4 registration.
If accepted, the result is registered and published.
The current framework gives ★4 a validity period of three years.
During those three years, the registered organization must conduct annual self-assessments and submit them to the evaluation body.
If significant changes affect the scope or compliance status, additional evaluation may be required.
Under SCS-100 §3.2, the organization also makes a self-conformity declaration and submits it with its self-assessment to the evaluation body. Renewal after three years requires third-party assessment.
The official term 実地審査 is used for on-site assessment; SCS-100 also permits its interviews and observation to be conducted remotely.
Official reference: IPA — SCS-100 basic regulations (PDF)
★3 vs ★4 at a glance
Swipe to compare all columns. Keyboard: focus this table and use the arrow keys.
| Area | ★3 | ★4 |
|---|---|---|
| Intended level | Baseline measures against general cyber threats | Broader measures for organizations with greater supply-chain impact |
| Current requirement count | 26 | 43 |
| Evaluation model | Expert-confirmed self-assessment | Third-party assessment |
| Document review | Yes | Yes |
| On-site assessment | Not the same third-party model as ★4 | Yes |
| Technical verification | Not the ★4 third-party technical-verification model | Yes |
| Supplier-risk management | Foundational | More developed, including important supplier visibility |
| Governance | Basic responsibility and policy | Stronger governance, reporting and continuous improvement |
| Detection | Basic monitoring | Stronger detection and analysis |
| Recovery | Foundational recovery preparation | More developed recovery planning |
| Current validity period | 1 year | 3 years; annual self-assessment |
| Must ★3 be obtained first? | — | No |
This is a simplified business explanation.
Companies preparing for formal evaluation should work from the current official IPA requirements and evaluation criteria.
Official reference: IPA — SCS-100 basic regulations (PDF) · IPA — ★3 / ★4 requirements and evaluation criteria
SCS covers seven major security areas
The official requirements are organized into seven major categories.
Six correspond to the functions of the NIST Cybersecurity Framework, with an additional category emphasizing supplier management.
Swipe to compare all columns. Keyboard: focus this table and use the arrow keys.
| SCS area | Business meaning |
|---|---|
| Governanceガバナンスの整備 | Who is responsible, what policy applies, and how management oversees security |
| Supplier Management取引先管理 | How security expectations and responsibilities are managed with business partners |
| Risk Identificationリスクの特定 | What assets, systems, services and vulnerabilities exist |
| Protection攻撃等の防御 | How accounts, networks, systems and information are protected |
| Detection攻撃等の検知 | How suspicious activity and abnormal behavior are identified |
| Incident Responseインシデントへの対応 | What happens when an incident occurs |
| Recoveryインシデントからの復旧 | How systems and operations are restored |
This structure is important because SCS is not simply about buying technical security tools.
It also deals with:
responsibility,
business relationships,
documentation,
incident procedures,
recovery,
and governance.
Official reference: METI / NCO — March 2026 SCS framework (IPA-hosted PDF) · IPA — ★3 / ★4 requirements and evaluation criteria
These business explanations are editorial summaries, not official requirement text.
Do companies need to meet every requirement?
For formal ★3 or ★4 registration, IPA states that the organization must satisfy the requirements and evaluation criteria defined for that level.
This is therefore different from a maturity assessment where a company might obtain a score even while leaving significant requirements unfulfilled.
However, the exact way organizations demonstrate conformity depends on their environment and the relevant evaluation criteria.
The framework does not require every organization to deploy exactly the same technical products.
That means SCS readiness should not begin with:
“Which security products do we need to buy?”
It should begin with:
“Which requirements apply to our scope, what are we already doing, what evidence do we have, and where are the actual gaps?”
Official reference: IPA — SCS FAQ · IPA — SCS-100 basic regulations (PDF)
No particular security product is mandatory
This point deserves its own section because it is commercially important.
METI explicitly states that meeting SCS requirements does not require installation of a particular cybersecurity product.
A smaller organization and a large enterprise may implement controls differently.
Their architecture may differ.
Their technologies may differ.
Their processes may differ.
What matters is whether the applicable requirement and evaluation criteria are satisfied.
Therefore, a company should be cautious if someone claims:
“You must buy Product X to obtain SCS.”
or:
“The government requires this particular service.”
SCS defines required security outcomes and controls.
It is not a government-approved product shopping list.
Official reference: METI — SCS policy and FAQ · METI / NCO — Warning about improper SCS solicitation
SCS is voluntary
Another misconception needs to be addressed clearly.
SCS is not a mandatory certification imposed on every Japanese business.
It is a voluntary framework.
The government does not automatically prohibit a business from operating because it does not have ★3 or ★4.
Nor does SCS itself automatically require a customer to terminate a supplier that has not obtained a star.
However, there is an important commercial distinction.
A customer and supplier may agree within their business relationship or contract that a particular security level is required.
A large buyer may therefore decide that suppliers performing certain important roles should meet a particular level.
In that sense:
SCS itself is voluntary.
But:
cybersecurity expectations may still become part of commercial relationships.
That is one reason businesses should understand SCS before customers begin asking about it.
METI and NCO have warned against sales claims that an unrated company is automatically prohibited from trading or excluded from bids. Those claims do not describe restrictions imposed by SCS.
Official reference: METI — SCS policy and FAQ · METI / NCO — Warning about improper SCS solicitation
Buyers should not simply demand ★4 from everybody
A large company may be tempted to say:
“For simplicity, all suppliers must obtain ★4.”
That is not necessarily good supply-chain risk management.
Different suppliers create different risks.
Consider:
Supplier A provides ordinary office consumables.
Supplier B operates a cloud platform containing sensitive customer information.
Supplier C has privileged remote access to production systems.
Supplier D supplies a component without which a factory cannot operate.
Their consequences are very different.
A more practical approach is:
- Understand the relationship
- Assess business and information dependency
- Determine the appropriate security expectation
- Communicate that expectation clearly
- Give the supplier a reasonable path to respond
- Review implementation
The star level should follow the risk.
The risk should not be invented to justify the star.
Buyers also need to consider the burden they place on suppliers
Supply-chain cybersecurity is not strengthened simply by passing every cost and administrative burden downstream.
METI and the Japan Fair Trade Commission have already addressed the relationship between cybersecurity requests and fair business practices.
Where buyers request additional cybersecurity measures that increase supplier costs, the parties should appropriately discuss those requirements and the resulting cost burden.
Cybersecurity requirements should therefore be implemented through partnership rather than surprise demands.
For a large buyer, good practice can include:
- explaining why a security level is needed;
- clearly identifying which suppliers are affected;
- providing reasonable preparation time;
- communicating available public support;
- considering the cost implications;
- and creating a process for questions and remediation.
A stronger supply chain requires capable suppliers—not merely stricter questionnaires.
Official reference: METI / JFTC — Supplier partnership and fair cost discussions · JFTC / METI — Supplier cybersecurity partnership guidance
What should buying organizations do now?
Even before formal operation begins, a buying organization can start preparing.
1. Map important supplier relationships
Identify suppliers that:
hold sensitive information;
connect to enterprise systems;
provide important IT services;
have privileged access;
support critical operations;
or could cause serious disruption if unavailable.
2. Segment suppliers by risk
Not every supplier requires identical controls.
Create a risk-based approach based on:
access,
data,
business dependency,
criticality,
and potential impact.
3. Compare existing questionnaires with SCS
Many companies already perform supplier-security reviews.
Rather than creating another parallel process, compare existing requirements with the SCS framework.
4. Decide how SCS could be used commercially
Possible uses may include:
formal ★ expectations;
using SCS requirements as a common security checklist;
using it in supplier onboarding;
or applying requirements only to particular supplier categories.
5. Design the exception process
What happens if an important supplier does not yet meet the expected requirement?
Possible outcomes may include:
remediation;
temporary controls;
risk acceptance;
additional monitoring;
contractual measures;
or, where justified, selection of another supplier.
The answer should be based on business risk rather than automatic punishment.
What should suppliers do now?
Suppliers should not wait until a major customer sends an urgent questionnaire.
The first step is not necessarily purchasing more technology.
It is understanding the current state.
A practical readiness process is:
- Define scope
- Map current controls
- Collect evidence
- Compare against ★3 / ★4 requirements
- Identify gaps
- Prioritize remediation
- Implement and document
- Run an internal readiness review
- Prepare for the appropriate official evaluation
This is much more efficient than trying to reconstruct evidence immediately before an application.
Illustrative Axton readiness process; not an official SCS application procedure.
Diagram 1 — How SCS can work in a business relationship
Illustrative Axton editorial model; consult official SCS rules for formal evaluation.
- BUYER
- Understand supplier risk
- Select appropriate security expectation
- Communicate requirement
- SUPPLIER
- Implement / demonstrate controls
- ★3 or ★4 evaluation where appropriate
- Result becomes visible
- BUYER + SUPPLIER
- Use common evidence to support the business relationship
SCS is intended to create a common language for supply-chain security, not simply another questionnaire.
Official reference: METI — SCS policy and FAQ
Diagram 2 — ★3 and ★4 evaluation paths
Illustrative Axton editorial model; consult official SCS rules for formal evaluation.
★3 · Expert-confirmed self-assessment
- Organization self-assessment
- SCS security expert review and advice
- Corrections if necessary
- Expert sign-off
- Management self-conformity declaration (自己適合宣言)
- Submission to SCS administration
- Registration / publication
- Annual renewal
★4 · Third-party assessment
- Organization self-assessment / self-conformity declaration
- Designated evaluation body
- Document review
- On-site assessment
- Technical verification
- Evaluation report
- Application to SCS administration
- Registration / publication
- Annual self-assessment during three-year validity
★3 is not a prerequisite for ★4. Registration follows acceptance by SCS administration; ★4 is reassessed for renewal after three years.
Official reference: IPA — SCS-100 basic regulations (PDF)
What is technical verification under ★4?
★4 includes technical verification as part of the third-party evaluation.
IPA’s current operating structure includes designated technical-verification providers.
Their role includes technical verification such as vulnerability assessment within the SCS evaluation process.
This does not mean every cybersecurity test available in the market automatically forms part of SCS.
Companies should rely on the final official evaluation guidance and the designated evaluation organization when determining what verification is required for their scope.
Official reference: IPA — Provider designation applications · IPA — Regulations and procedures
What is an SCS security expert?
An SCS security expert has a specific role within the official framework.
For ★3, the expert reviews and advises on the applicant organization’s self-assessment.
For ★4, appropriately qualified experts may serve in evaluation-responsibility roles within evaluation bodies.
The current framework requires an SCS security expert to satisfy both qualification/competence requirements and SCS-specific training requirements before registration.
Relevant qualifications currently listed by IPA include certain recognized Japanese and international security/audit certifications.
Therefore:
Being a cybersecurity consultant does not automatically make someone an official SCS security expert.
The person must satisfy the official requirements and be registered within the SCS framework.
IPA currently lists Registered Information Security Specialist (情報処理安全確保支援士), Certified Information Security Auditor (公認情報セキュリティ監査人), CISSP, CISA, CISM or ISO 27001 Lead Auditor credentials. Maintaining a listed qualification, completing SCS-specific training and registration with SCS administration are required; a credential alone does not confer SCS expert status.
Official reference: IPA — SCS detailed information · IPA — SCS FAQ · IPA — SCS-100 basic regulations (PDF)
Axton Group is not an SCS certification body
This point should be absolutely clear.
Axton Group LTD Japan does not represent itself as:
an official SCS evaluation body;
an official technical-verification provider;
a registered SCS security expert;
or an official SCS certification authority,
unless and until the company is formally designated or registered for the relevant role.
That does not prevent an organization from receiving legitimate preparation support.
Depending on project scope and capability, Axton may support areas such as:
- understanding SCS requirements;
- current-state review;
- identifying evidence;
- mapping policies and processes;
- identifying gaps;
- developing a remediation roadmap;
- improving supplier-security processes;
- organizing responsibilities;
- and coordinating appropriate security specialists.
Formal ★ evaluation and official roles must follow the SCS framework.
What is the relationship between SCS and ISMS?
SCS and ISMS should not be treated as identical systems.
METI describes them as complementary.
SCS ★3 and ★4 use a baseline-oriented approach.
They identify specific cybersecurity measures considered effective against representative threats and supply-chain risks.
ISMS is built around an information-security management system and risk-based management approach.
An organization with ISMS certification should therefore not automatically assume:
“We already have ISMS, so ★4 is automatic.”
Likewise, an SCS star should not be interpreted as replacing every purpose of ISMS.
Organizations that use both should look at how their existing governance, evidence and controls can support SCS readiness while addressing any additional SCS-specific requirements.
Official reference: METI — SCS policy and FAQ · METI / NCO — March 2026 SCS framework (IPA-hosted PDF)
What about ★5?
★5 is planned as a future, more advanced level.
The government currently describes it as addressing more sophisticated threats, potentially including unknown attacks, through stronger risk management and best-practice cybersecurity measures.
But:
★5 requirements, evaluation criteria and implementation timing are still under development.
Businesses should therefore avoid making procurement rules or security claims based on a ★5 framework that has not yet been finalized.
For now, the operational focus is ★3 and ★4.
Official reference: IPA — SCS FAQ
What about ★1 and ★2?
The SCS framework references IPA’s existing SECURITY ACTION program in relation to lower-level security initiatives.
The operational SCS evaluation framework currently being prepared focuses on ★3 and ★4, with ★5 under development.
Companies should not assume that every star number represents the same type of evaluation mechanism.
Official reference: METI / NCO — March 2026 SCS framework (IPA-hosted PDF)
Diagram 3 — SCS readiness is an operating process
Illustrative Axton editorial model; consult official SCS rules for formal evaluation.
- SCOPE
What organization / IT environment is being evaluated?
- CURRENT STATE
What controls already exist?
- EVIDENCE
Can those controls be demonstrated?
- GAP
Which SCS requirements are not yet satisfied?
- REMEDIATION
Policy / people / process / technology
- VERIFY
Does the remediation actually work?
- EVALUATE
★3 expert-confirmed self-assessment or ★4 third-party assessment
- REGISTER
Register when accepted by SCS administration
- MAINTAIN
Annual checks, changes and reassessment where required
↺ Maintain → revisit scope and current state. SCS readiness is not a one-time documentation exercise.
The seven areas companies should examine
- Governance
- Are security responsibility, policy, management oversight and improvement processes defined?
- Supplier Management
- Do we know which external parties matter and what security responsibilities they have?
- Risk Identification
- Do we know our assets, networks, external services and vulnerabilities?
- Protection
- Are identities, access, systems, networks and important information appropriately protected?
- Detection
- Can suspicious activity be identified and analyzed?
- Incident Response
- Is there a defined process for managing a security incident?
- Recovery
- Can important systems and business operations be restored?
These questions are an executive-level summary.
Formal preparation must use the detailed official requirements and evaluation criteria.
Official reference: IPA — ★3 / ★4 requirements and evaluation criteria
A supplier-security spreadsheet is not the same as supplier-security management
SCS can be useful even before a company formally makes stars part of its contracts.
Imagine this process:
- Supplier questionnaire sent
- Spreadsheet returned
- Stored in a folder
- Nothing happens until next year
The organization may have collected information.
But did it manage risk?
A stronger process is:
- Supplier identified
- Criticality determined
- Appropriate security requirement selected
- Evidence submitted
- Gap detected
- Remediation owner assigned
- Deadline
- Evidence rechecked
- Approved or escalated
- Periodic reassessment
That is where supply-chain security becomes an ongoing business process rather than an annual questionnaire exercise.
An illustrative management process, not an exact workflow mandated by SCS.
Cybersecurity workflow automation can support SCS operations
SCS itself does not require a specific workflow platform.
But organizations with large supplier ecosystems may eventually face an operational challenge:
How do we manage:
hundreds of suppliers,
different required levels,
questionnaires,
documents,
evidence,
exceptions,
remediation,
approvals,
renewals,
and management visibility?
That can become a workflow problem.
A well-designed process may help organizations:
send requirements consistently;
collect evidence;
track missing information;
route security reviews;
assign remediation;
escalate overdue gaps;
record decisions;
manage reassessments;
and maintain an audit trail.
Technology should support the security process.
It should not replace security judgment.
SCS does not require Fluyenta, and Fluyenta is not an official SCS product. A workflow platform supports notifications, evidence, review routing and audit history; it does not replace security judgment.
Buyer and supplier responsibilities are different
Swipe to compare all columns. Keyboard: focus this table and use the arrow keys.
| Buyer / commissioning organization | Supplier / commissioned organization |
|---|---|
| Understand supplier risk | Understand customer expectations |
| Select proportionate requirements | Determine applicable scope |
| Communicate expectations clearly | Assess current controls |
| Avoid unnecessary one-size-fits-all demands | Collect evidence |
| Consider implementation burden and cost | Remediate genuine gaps |
| Define exception/remediation process | Maintain controls |
| Monitor important dependencies | Communicate material changes |
| Reassess relationships as risk changes | Prepare for reassessment |
Supply-chain security works best when neither side treats the process as a paperwork exercise.
What SCS does not mean
MythSCS is mandatory for every Japanese company.
FactSCS is voluntary. Companies may agree proportionate requirements through a business relationship.
MythNo star means business is prohibited.
FactSCS itself does not impose a trading or bidding ban.
MythEvery supplier needs ★4.
FactExpected measures should reflect risk and the particular business relationship.
MythOne security product is mandatory.
FactMETI explicitly says no particular security product is mandated by SCS.
Myth★4 guarantees a company will never be breached.
FactNo cybersecurity evaluation guarantees zero incidents.
MythSCS replaces every security standard and industry requirement.
FactSCS complements ISMS and does not replace sector regulation or OT guidance.
MythAny cybersecurity consultant can issue SCS stars.
FactOfficial evaluation, expert and registration roles are governed by the SCS framework.
Understanding these distinctions helps avoid unnecessary cost, fear and procurement pressure.
What should companies do before March 2027?
For buyers:
identify which suppliers actually matter.
For suppliers:
understand what customers may reasonably ask of you.
For both:
read the official ★3 and ★4 requirements now rather than waiting for the first urgent request.
A useful preparation sequence is:
- determine the relevant business relationships;
- identify the IT environment and scope;
- compare current controls with the official requirements;
- collect evidence;
- identify genuine gaps;
- prioritize remediation;
- understand which level is appropriate;
- confirm the latest IPA application and evaluation process before applying.
The goal should not simply be:
“Get a star.”
The goal should be:
Build cybersecurity controls that make the organization a safer and more reliable participant in the supply chain—and use SCS to make that status easier for business partners to understand.
Frequently Asked Questions
Is SCS mandatory?
No. SCS is a voluntary framework.
The government does not require every Japanese company to obtain ★3 or ★4.
However, companies may agree to cybersecurity requirements as part of their commercial relationships or contracts.
When will ★3 and ★4 begin?
IPA currently plans to begin operation around March 2027.
Because implementation details are still being published, companies should confirm the current schedule before applying.
What is the difference between ★3 and ★4?
★3 represents a foundational level against general cyber threats and uses expert-confirmed self-assessment.
★4 contains broader measures for organizations with greater supply-chain impact and requires third-party assessment, including on-site review and technical verification.
How many requirements are there?
The current framework contains 26 requirements for ★3 and 43 for ★4.
Do I need ★3 before applying for ★4?
No.
The official framework explicitly states that prior ★3 registration is not required before seeking ★4.
Do we need to satisfy every requirement?
IPA states that organizations seeking ★3 or ★4 must satisfy the requirements and evaluation criteria defined for that level.
Does SCS require a particular security product?
No.
METI explicitly states that no particular cybersecurity product is required merely to satisfy SCS.
Is SCS a cybersecurity ranking?
No.
The government describes it as a mechanism for evaluating and visualizing implementation of cybersecurity measures, not as a competitive company-ranking system.
Does having ★4 mean a company cannot be hacked?
No.
A cybersecurity evaluation demonstrates conformity with defined requirements at a point in time and within a defined scope. It cannot guarantee that an organization will never experience an incident.
Does ISMS automatically give us ★3 or ★4?
No.
SCS and ISMS are described as complementary, but they use different structures and evaluation approaches. Existing ISMS controls may support SCS readiness, but companies still need to assess the SCS requirements directly.
Can Axton Group issue an SCS star?
Not unless Axton becomes formally designated or registered for the appropriate official role.
Axton should not represent itself as an SCS evaluation body or certification authority without such status.
Can Axton help us prepare?
Depending on the agreed project scope, Axton may support readiness activities such as requirement mapping, current-state review, evidence inventory, gap identification, remediation planning, supplier-security process design and coordination with appropriate specialists.
Formal evaluation must follow the official SCS framework.
What should we do first?
Start by identifying your scope and business dependencies.
Then compare existing cybersecurity controls and evidence against the current official ★3 or ★4 requirements.
Do not begin by purchasing security products without first understanding the actual gap.
Editorial note
This article was prepared by Axton Group LTD Japan using official materials published by Japan’s Ministry of Economy, Trade and Industry (METI), National Cybersecurity Office (NCO), and Information-technology Promotion Agency, Japan (IPA).
Descriptions of ★3, ★4, evaluation processes, validity periods and implementation schedules are based on official SCS materials available at the time of publication.
The diagrams, readiness process and business examples in this article are explanatory Axton editorial models and are not official METI, NCO or IPA frameworks.
SCS remains under implementation, and procedures, fees, guidance and schedules may be updated. Organizations considering formal registration should confirm the latest official IPA information.
Axton Group LTD Japan does not represent itself as an official SCS evaluation body, technical-verification provider, SCS security expert or certification authority unless such status is separately obtained and publicly confirmed.
Related reading
Official sources
- IPA — SCS official portalPublished 2026-04-21; notices through 2026-09-18
- IPA — SCS detailed informationUpdated 2026-05-29
- IPA — SCS FAQUpdated 2026-05-29; read alongside newer regulations and fee notice
- IPA — Regulations and proceduresUpdated 2026-09-18; rules 2026-08-28, criteria/procedures 2026-09-11
- IPA — SCS-100 basic regulations (PDF)2026-08-28; §§2.1.9–2.1.11, 3.1–3.2, 5.5–5.9
- IPA — Evaluation bodies and SCS security expertsLatest recorded update 2026-09-18
- IPA — Provider designation applicationsPublished 2026-09-18; updated 2026-10-07
- IPA — Provider application FAQ (PDF)2026-10-07 version; provider roles, not company star applications
- METI / NCO — March 2026 SCS framework (IPA-hosted PDF)2026-03-27; pp8–9, 13, 16–24, 26–28, 37
- IPA — ★3 / ★4 requirements and evaluation criteria2026-04-21; official March 2026 requirements workbook
- METI — SCS policy and FAQPage updated 2026-07-06; FAQ dated 2026-03-27
- METI / NCO — Warning about improper SCS solicitation2026-04-27; also linked by IPA on 2026-04-30
- METI / JFTC — Supplier partnership and fair cost discussionsPublished 2022-10-28; updated 2025-12-26 with SCS examples
- JFTC / METI — Supplier cybersecurity partnership guidance2022-10-28; §3.2 on requirements and cost discussions
- IPA — Published SCS fee schedule (PDF)2026-09-18; registration fees are separate from expert/evaluation charges
Checked on 7 October 2026. English summaries are editorial explanations of the Japanese official documents. Formal applications should use the latest IPA documents.