Defense Supply Chain Security Standards (MOD New Standards & NIST SP 800-171) and SOC Requirements

For companies involved in the manufacture of defense equipment or providing related services, compliance with the information security standards established by the Ministry of Defense (MoD) may be a condition of contract award. This applies to procurement contracts with the MoD signed on or after April 1, 2023, that involve the handling of information requiring protection. Subcontractors and sub-subcontractors handling such information are also required to implement security measures based on special contract clauses. Mid-tier companies and SMEs—including parts manufacturers, processing vendors, and software developers—that previously believed "our company is not in the defense industry" must also review their handled information and contract terms.

The background to this is the normalization of attacks targeting supply chains. In the "Top 10 Information Security Threats 2026" published by the IPA (Information-technology Promotion Agency) in January 2026, "attacks targeting supply chains and subcontractors" was selected as the 2nd highest threat for organizations, marking its eighth consecutive year on the list (IPA, 2026). The tactic of using poorly defended partners as stepping stones to reach the ultimate target is heavily guarded against in the defense sector, where sensitive information flows across multiple tiers of companies.

This article outlines the requirements of the MoD's information security standards and covers NIST SP 800-171 Rev.3 as a reference. We interpret the requirements for "logging, monitoring, incident response, and auditing" based on the original texts and explain how to apply them to Security Operations Center (SOC) operations. It also covers the talent and cost challenges faced by mid-tier manufacturers, the utilization of AI SOC, and a roadmap for preparation.

The SCS evaluation system promoted by the Ministry of Economy, Trade and Industry (METI) and the IPA is a separate program from the MoD's procurement standards. For details on evaluation tiers, scheduled start dates, and preparation for corporate IT infrastructure, please see What is the SCS Evaluation System? Target Companies, Differences Between 3-Star and 4-Star, and Preparation Steps.

Overview of the Ministry of Defense "Defense Industry Cybersecurity Standards"

Commonly referred to as the "Defense Industry Cybersecurity Standards" or the "New MoD Standards," the official name of the guidelines is the "Information Security Standards for the Procurement of Equipment and Services." According to the Acquisition, Technology & Logistics Agency (ATLA) public page, these standards were established in March 2022 to counter the growing risk of cyberattacks, and apply to the management of "information requiring protection" handled by companies under contract (ATLA, 2025). Companies entering into contracts containing special clauses with the MoD must implement security measures based on these standards.

Regarding the timeline for implementation, the ATLA FAQ explains: "These standards apply to all contracts with the MoD signed on or after April 1, R5 (2023) for the procurement of equipment and services that include the handling of information requiring protection" (ATLA FAQ, 2024). This means that for contracts involving such information signed on or after April 1, 2023, compliance with the new standards has already been required. Regarding transitional measures from previous standards, the FAQ states that "under the regulations, transitional measures will expire at the end of March R10 (2028)," while also noting that most defense-related companies are expected to complete the transition within 1 to 2 years.

Scope of Protection and Relationship with NIST SP 800-171

The "information requiring protection" targeted by these standards is defined as "procurement information concerning equipment and services that corresponds to the MoD's 'internal use only' or 'caution' classifications, and is designated by the government in the information security specification sheet." Classified information such as Confidential, Secret, or Special State Secrets is handled under a separate framework and is outside the scope of these standards. Consequently, even unclassified design or procurement information becomes subject to the standards once designated in the specification sheet, which is the key practical point for many supplier companies.

Regarding the security level, the FAQ explicitly states that "the security requirements are equivalent to NIST SP 800-171" (ATLA FAQ, 2024). Additionally, the ATLA page notes that the new standards were established by adding "detection," "response," and "recovery" requirements. While traditional information security focused heavily on preventive controls and preventing data leakage, the new standards assume that intrusions or anomalies will occur, requiring companies to possess the capability to detect, respond to, and recover from incidents. This "detection, response, and recovery" is the exact area that directly overlaps with the functions of a SOC.

The scope of application to the supply chain is also clear. The ATLA page states, "Companies subcontracted by prime contractors to perform work involving 'information requiring protection' must also implement measures based on these standards." The FAQ further clarifies, "Special clauses dictate application to subcontractors. It also applies to sub-subcontractors and beyond." The standards undergo periodic updates. The latest R7 (2025) edition (ATLA (Adm) No. 137) took effect on July 1, 2025, and documents submitted on or after September 1, 2025, must use the new templates. Organizations must always refer to the latest edition during implementation.

Structure of the Standards

The R7 (2025) edition consists of the main text (Part 1) and an appendix, "System Security Implementation Guidelines." Part 1 contains 14 chapters covering Purpose, Definitions, Scope, followed by Information Security Policy, Organizational Security, Management of Information Requiring Protection, Information Security Education and Training, Physical and Environmental Security, Controls for Protection Systems, Response to Information Security Incidents, Actions in the Event of Information Security Incidents, Risk Assessment, Security Auditing, and Auditing by the MoD. The appendix defines technical requirements including System Security Implementation Plan, Configuration Management, Basic Defense of Protection Systems, Access Control, Identification and Authentication, Communication Control, System Monitoring, System Logs, Vulnerability Scanning, Backup, and System Maintenance.

Among these, the areas most relevant to SOC operations are the chapters in Part 1 covering "Response to Information Security Incidents," "Actions in the Event of Information Security Incidents," "Security Auditing," and "Auditing by the MoD," alongside the appendix chapters for "System Monitoring," "System Logs," and "Vulnerability Scanning." Specific requirements are discussed below.

Structure of NIST SP 800-171 Rev.3 and the Monitoring, Auditing, and Incident Response Requirement Families

NIST SP 800-171 is a publication by the National Institute of Standards and Technology (NIST) titled "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations." It defines recommended security requirements to protect the confidentiality of CUI (Controlled Unclassified Information—government information that is unclassified but requires safeguarding) when residing in non-federal systems and organizations. The current Rev.3 was released in May 2024, replacing the January 2021 Rev.2 (NIST, 2024). While widely known as the standard required for suppliers in US defense procurement, it is also the reference framework that the Japanese MoD standards align with as "equivalent."

The requirements in Rev.3 are derived from the NIST SP 800-53 moderate baseline controls, tailored to exclude responsibilities that belong to the federal government or do not relate to the confidentiality of CUI. The requirements are organized into 17 families, numbered 03.01 through 03.17. A key feature of Rev.3 is the inclusion of ODPs (Organization-Defined Parameters) within the requirement statements. Specific values, such as the frequency of log reviews or the deadline for incident reporting, are designed to be defined by the implementing organization or the purchasing authority. Even when complying with the Japanese "equivalent" standards, Japanese companies must note that the design of frequencies and durations is partially left to their own discretion.

The MoD standards were established in March 2022, whereas Rev.3 was published later in May 2024. The FAQ does not specify which revision of SP 800-171 is deemed equivalent. In practice, the primary requirement is compliance with the original Japanese MoD standards and specific contract clauses; the NIST documents serve as a reference to understand the background of the requirements and to audit internal measures. Below, we highlight the families related to SOC operations.

03.03 Audit and Accountability

This family defines requirements for log (audit record) generation, protection, and analysis. Rev.3 contains 8 requirements: 03.03.01 Event Logging, 03.03.02 Audit Record Content, 03.03.03 Audit Record Generation, 03.03.04 Audit Log Processing Failures, 03.03.05 Audit Record Review, Analysis, and Reporting, 03.03.06 Audit Record Reduction and Report Generation, 03.03.07 Time Stamps, and 03.03.08 Protection of Audit Information (NIST, 2024).

The core requirement from a SOC perspective is 03.03.05. The text states: "Review and analyze system audit records [Assignment: organization-defined frequency] for indications and the potential impact of inappropriate or unusual activity." This requires organizations to review and analyze system audit records at an organization-defined frequency to detect indications and potential impact of inappropriate or unusual activity. Simply "retaining" logs does not satisfy the requirement; it demands an active operation of "reviewing, analyzing, and reporting." Requirements such as 03.03.04 (handling log processing failures) and 03.03.08 (protecting audit information) demand that logs remain continuous and tamper-proof, directly impacting the design of log infrastructure.

03.06 Incident Response

The Incident Response family includes 5 requirements: 03.06.01 Incident Handling, 03.06.02 Incident Monitoring, Reporting, and Response Assistance, 03.06.03 Incident Response Testing, 03.06.04 Incident Response Training, and 03.06.05 Incident Response Plan. The text for 03.06.01 states: "Implement an incident-handling capability consistent with the incident response plan including preparation, detection and analysis, containment, eradication, and recovery" (NIST, 2024). Requirement 03.06.02 requires tracking, recording, and reporting incidents within organization-defined time limits, where the reporting deadline is again defined by the organization as an ODP.

03.14 System and Information Integrity, 03.12 Security Assessment and Monitoring

The "System and Information Integrity" family includes 03.14.01 Flaw Remediation, 03.14.02 Malicious Code Protection, 03.14.03 Security Alerts, Advisories, and Directives, 03.14.06 System Monitoring, and 03.14.08 Information Management and Retention. The text for 03.14.06, which is closest to SOC operations, states: "Monitor the system to detect attacks and indicators of potential attacks, unauthorized connections, and unauthorized use." Requirement 03.14.02 requires detecting and eradicating malicious code at system entry and exit points, while 03.14.03 requires continuously receiving security alerts and advisories from external organizations, which maps to EDR and threat intelligence operations (NIST, 2024).

The "Security Assessment and Monitoring" family includes 03.12.01 Security Assessments, 03.12.02 Plan of Action and Milestones, 03.12.03 Continuous Monitoring, and 03.12.05 Information Exchange. Requirement 03.12.03 states: "Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments." Additionally, Rev.3 includes the Supply Chain Risk Management (03.17) family, positioning risk management inclusive of partners as part of the overall requirement framework.

Specific Requirements for Logs, Monitoring, Incident Response, and Auditing in MoD Standards

What exactly do the MoD standards require? Below are the requirements related to SOC operations extracted from the R7 (2025) edition main text and related circulars (ATLA, 2025).

Acquiring, Analyzing, and Retaining System Logs

Appendix 9, "System Logs," states: "Defense-related companies shall automatically acquire records on the system regarding the following matters in order to detect unauthorized operations and communications within the protection system," listing "details of actions on protected data" and "details of operations by each user of the protection system" as targets for acquisition. Regarding analysis, it dictates: "The person in charge of the protection system shall periodically analyze system logs, and when conducting analysis, shall aggregate system logs acquired from protection system components and perform overall and cross-sectional analysis." Documents recording analysis results must be promptly reported to the supervisor or protection system administrator. Regarding retention, it states: "When retaining system logs as paper documents, they shall be stored in locked lockers, etc., and when saving as data, they shall be saved using encryption and retained or saved for the necessary period." The main text does not specify a concrete number of years, leaving the "necessary period" to be defined by the company.

The key phrase here is "aggregate and perform overall and cross-sectional analysis." Rather than viewing isolated logs from endpoints, servers, identity providers, and network devices individually, companies must collect and correlate them. This points directly to log correlation analysis via SIEM, aligning with NIST 03.03.05.

System Monitoring

Appendix 8, "System Monitoring," first states: "Defense-related companies shall install equipment and software necessary to collect information required for detecting unauthorized access and changes, unauthorized use of accounts and privileges, unauthorized communications, and malicious code, etc. (hereinafter referred to as 'unauthorized access, etc.') within the protection system." It then dictates that, in conducting monitoring, companies "shall continuously monitor behavior on the system and utilize the analysis results of system logs generated under the provisions of Section 9, Paragraph 1." It also contains sections regarding monitoring methods, response upon detecting unauthorized access, and the utilization and retention of information obtained through monitoring. The explicit requirement for "continuous monitoring" and the "utilization of log analysis results" serves as the starting point when designing a SOC structure.

Incident Preparation and Reporting

In Part 1, "Response to Information Security Incidents," it states: "Management, etc., shall establish an information security incident response plan in preparation for the occurrence of information security incidents and events," listing "preservation of evidence and investigation of causes" and "recovery from incidents" as items to be defined in the plan. It also requires that "information security incident response tests shall be conducted periodically to verify the effectiveness of the incident response plan and discover potential weaknesses or flaws," matching NIST 03.06.03 (testing) and 03.06.05 (planning).

Regarding reporting when an incident occurs, the standard dictates: "Upon receiving a report of an information security incident, etc., the supervisor shall take appropriate measures and immediately report all details that can be grasped at that moment, followed promptly by detailed reports to the MoD." This is a two-step approach: "immediately" for initial findings, and "promptly" for details. The circular defining the MoD-side receiving procedures (ATLA (Adm) No. 4239) provides a reporting template containing company name, contact info, brief details of the initial report, alongside "details of currently known facts," "actions taken so far," and "main affected contracts." The circular also notes that reports from subcontractors must be routed through the prime contractor that has the direct contract with the MoD, meaning subcontractors must confirm this reporting path in advance.

Internal Audits and MoD Audits

Part 1, "Security Auditing," states: "The supervisor shall have the audit department conduct a security audit at least once a year and when deemed necessary, such as when major changes occur in the company's information security." It requires that the audit department include at least one person from outside the audited department. In addition to this, there are audits conducted by auditors designated by the MoD. The audit guidelines (ATLA (Adm) No. 4210) define "maintenance audits," which follow the initial audit, as "audits conducted periodically at least once a year starting from the fiscal year following the initial audit to confirm compliance with special clauses and the effectiveness and compliance status of the information security policy, etc." (ATLA, 2025).

The audit checkpoints include confirming that "system logs of the protection system are appropriately acquired, analyzed, saved, or retained in accordance with established procedures." On-site audits combine visual inspections, document reviews, interviews, observations, and system testing. Any findings must be promptly corrected and reported, with improvements verified during re-audits. For subcontractors, prime contractors must collect and submit the subcontractor's security compliance confirmation sheet, which is then reviewed by the MoD auditor. This places prime contractors in a position where they bear accountability not only for their own security measures but also for those of their subcontractors.

How to Meet These Requirements Through SOC Operations

A SOC is a specialized team or function that monitors an organization's systems and networks, detects and analyzes threats, and initiates responses (the basics of roles and structures are explained in "What is a SOC? Roles, Tier Structures, and the Basics and Limitations of 24/7/365 Operations"). While MoD standards and NIST SP 800-171 define "what must be met," the "how to structure and run the operations" is left to the enterprise's design. Here, we translate the requirements into SOC operations.

Designing Log Collection and Preservation

First, map the components of the protection system and identify which logs from which devices and services can prove the "details of actions on protected data" and "details of operations by each user." Typical logs include file server or CAD/PLM system access logs, authentication success/failure logs, endpoint EDR logs, firewall and proxy traffic logs, and cloud service activity logs. Aggregating these into a SIEM establishes the foundation for "overall and cross-sectional analysis."

Next, prepare for log gaps and tampering. As assumed in NIST 03.03.04, set up mechanisms to detect when log forwarding stops or storage capacity is depleted. Cross-sectional analysis cannot function without time synchronization (03.03.07). In line with the standards, encrypt saved logs and restrict access rights to analysis personnel (03.03.08). Because the standards do not specify a retention duration, it is crucial to define and document the retention period based on contract terms, ease of explanation during audits, and internal risk assessments. This is essentially the process of filling in the ODPs internally.

Achieving Continuous Monitoring Through People and Technology

The "continuous monitoring" required by the standards is not automatically satisfied by simply installing monitoring hardware and software. If alerts generated by detection mechanisms are not reviewed by a human to determine if they represent a true threat and escalate them if necessary, auditors may conclude that "logs are collected but not analyzed." A structure that can maintain continuous monitoring, validation, and response upon detection is required. Design the monitoring and response structure based on the target systems and contract conditions. Establish clear escalation paths to hand over critical incidents to the supervisor or protection system administrator, including during nights and holidays.

For many mid-tier manufacturers, achieving this with shift work using only internal staff is impractical. The choice between in-house operations, outsourcing, or combining automated tools depends on the balance of head count, budget, and response speed. The framework for this decision is detailed in "SOC Construction Costs and Steps: Realistic Methods for Mid-Tier Companies to Build 24/7 Monitoring."

Establishing Incident Response Procedures and Reporting

In the incident response plan, define the scope handled by the SOC and the scope handled by the supervisor/CSIRT, following the stages of NIST 03.06.01 ("preparation, detection and analysis, containment, eradication, and recovery") and incorporating the standards' requirements for "preservation of evidence, root cause investigation, and recovery." Generally, the SOC handles incident detection, initial analysis, and early containment such as isolating endpoints or disabling accounts. Deciding whether an event constitutes an official incident, making reporting decisions to the MoD, and notifying business partners are handled by a team centered around the supervisor.

In reporting operations, aim to be able to fill out the initial report items ("details of currently known facts," "actions taken so far," "main affected contracts") quickly after discovery. This requires the SOC's investigation logs to contain the scope of affected endpoints, accounts, and data, as well as actions taken, recorded in chronological order. Subcontractors should map out the reporting paths and contacts through the prime contractor for each contract and verify during periodic tests that communication channels work. Specific procedures from detection to containment are covered in "Incident First Response and SOC Collaboration: Practical Runbooks from Detection to Containment."

Ensuring Audit-Ready Evidence

Auditors verify whether logs are acquired, analyzed, and saved "in accordance with established procedures." Therefore, the required evidence includes the procedures themselves, records of conducted analyses, documents reporting analysis results to supervisors, and records of retention status. In SOC operations, investigation logs, decision-making rationales for each alert, response histories, and daily/monthly reports naturally serve as the required documentation. The goal of operational design is to continuously accumulate these records in a way that withstands annual internal audits and annual maintenance audits, keeping them ready for retrieval at any time.

Challenges Faced by Mid-Tier Manufacturers

When translating requirements into daily operations, mid-tier and SME manufacturers commonly face three challenges:

• Talent: Many companies lack dedicated security staff, or have 1 to 2 members from the IT department handling security as a dual role, making it difficult to run manual first-level alert triage during nights and holidays. Hiring and training talent with log analysis expertise is also highly challenging.

• Cost: On top of initial implementation costs for SIEM and EDR, monitoring and analysis operations incur ongoing annual costs. For companies where defense-related revenue is only a small part of overall sales, the cost feels disproportionately heavy relative to contract size.

• Multi-Tiered Supply Chains: Prime contractors must collect and submit compliance sheets from subcontractors, meaning the security level of subcontractors directly impacts the prime's audit. Conversely, subcontractors are often asked by multiple primes to submit different formats at different times, fragmenting their response efforts.

Additionally, the timeline has shifted. Several years have passed since the standards were established, and as the FAQ notes, many companies have completed the transition to the new standards over the past 1 to 2 years. Consequently, the challenge is moving from "completing the initial implementation" to "sustaining operations that can withstand annual maintenance audits." The "detect, respond, and recover" capabilities added in the new standards cannot be satisfied by documentation alone; real-world daily operations are tested during audits. Gaps where operational reality does not match policy documents are highly visible weaknesses in this domain.

Automating Evidence and Reporting while Reducing Manual Hours via AI SOC

To address these challenges, AI SOC has recently emerged as a viable option. An AI SOC is a system where AI agents autonomously investigate and respond to alerts from EDR or SIEM by replicating the investigation methodologies of expert analysts, differing fundamentally in structure from traditional SOCs that rely on manual first-level triage (for details on how it works, see "What is an AI SOC? Mechanisms, Differences from Traditional SOC, and Key Benefits Explained"). In relation to MoD standards, it supports operational compliance in the following ways:

First is the effectiveness of "continuous monitoring." In Yagura AI SOC, AI agents investigate alerts from EDR and SIEM 24/7/365, supporting the primary investigation for administrators. The actual scope of investigation and the number of uninvestigated alerts vary depending on integrated sources and available telemetry. It is crucial to verify the investigation rate in your environment to explain the scope and status of monitoring.

Second is the automated generation of audit evidence. In an AI SOC, the AI agent's investigation path—detailing which logs were correlated and the rationale behind the verdict—is recorded as an investigation log. Documenting this process and conclusion allows the "documents recording analysis results" and "reports to supervisors" required by the standards to be accumulated as a natural byproduct of operations. Combining this with Yagura AI SIEM, which centralizes scattered logs and automatically generates daily security reports, provides the necessary evidence for "periodic analysis."

Third is the speed of reporting and response. The investigation logs compiled by the AI provide the raw material to quickly fill in the "details of currently known facts" and "actions taken so far" needed for initial reports. Measure the time required to gather reporting details and complete remediation in your environment. Fourth is manual hours. Validate how much the dual-role administrator's workload can be reduced through automated first-level support, securing the time needed for incident response plan updates, testing, and audit preparation.

Yagura AI SOC is a proprietary service that integrates with over 100 security products, including EDR, SIEM, and identity management tools. It can be deployed utilizing existing investments such as Microsoft Sentinel. Its context memory learns the specific environment, improving investigation accuracy, which is highly suited for manufacturing environments where configurations differ per site. Yagura counts manufacturers in the defense supply chain as one of its primary customer segments. However, AI does not replace the judgment of the supervisor. Declaring an official incident and reporting to the MoD remain human responsibilities, and the organizational roles required by the standards (such as supervisors and protection system administrators) remain unchanged. AI SOC is best positioned as the foundation that enables these roles to sustain "continuous monitoring," "cross-sectional analysis," and "evidence preservation" with realistic manual effort.

Roadmap for Preparation

Finally, we outline the steps to align with the standards and establish a SOC structure. Companies that have already completed initial alignment can use this to review their readiness for maintenance audits and updates.

1. Inventory Contracts and Scope: Identify contracts containing special clauses, information requiring protection designated in the specification sheets, and the scope of protection systems handling that information. Map out the flow of data to subcontractors and sub-subcontractors.

2. Gap Analysis: Evaluate current status across documentation, technology, and operations, referencing Part 1 and the appendix of the MoD standards, alongside NIST SP 800-171 Rev.3 03.03, 03.06, 03.12, and 03.14. Verify specifically if "evidence of active operations" exists.

3. Establish Log and Monitoring Infrastructure: Define log sources, retention periods, and analysis frequencies. Implement SIEM ingestion, time synchronization, encryption, tamper prevention, and gap detection.

4. Determine 24/7 Monitoring Structure: Choose between in-house, outsourcing, AI SOC, or a hybrid model based on staff, budget, and response speed, defining escalation paths up to the supervisor.

5. Refine Incident Plans and Reporting Paths: Establish procedures to quickly fill out initial reporting templates, define reporting paths including those routed through prime contractors, and outline evidence preservation and recovery steps, validating them through periodic tests.

6. Establish Audit Cycles: Build annual plans that include internal audits at least once a year, evidence organization for maintenance audits, remediation of findings, and tracking of standard updates like the R7 (2025) edition.

Conclusion

The Ministry of Defense's "Information Security Standards for the Procurement of Equipment and Services" apply to procurement contracts signed on or after April 1, 2023, that involve the handling of information requiring protection. Subcontractors and sub-subcontractors handling such information are also required to implement security measures based on special clauses. Aiming for equivalence with NIST SP 800-171, the standards mandate automatic log acquisition and cross-sectional analysis, continuous monitoring, incident response planning, rapid reporting, and audits at least once a year. It is crucial to design a structure capable of continuous monitoring, validation, and response upon detection in accordance with target systems and contract conditions.

These requirements cannot be met by simply implementing tools or drafting policies. Organizations are evaluated on their ability to review and judge alerts, record analysis results, and remain ready to report incidents, including during nights and holidays. For mid-tier manufacturers facing talent and budget constraints, automating investigations and evidence generation via AI agents is becoming a powerful option to run these operations with realistic effort. We recommend starting with an inventory of contracts and scope, and gradually building towards a structure that maintains clear operational evidence.

Related Services: Learn more about "Yagura AI SOC," where AI agents autonomously investigate and respond to EDR and SIEM alerts 24/7/365, helping sustain continuous monitoring and analysis evidence as required by MoD standards.

References

• NIST, SP 800-171 Rev. 3 "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations" (2024): https://csrc.nist.gov/pubs/sp/800/171/r3/final

• NIST, SP 800-171 Rev. 3 Main PDF (2024): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf

• ATLA, "Regarding Information Security Standards for the Procurement of Equipment and Services" (2025): https://www.mod.go.jp/atla/cybersecurity.html

• ATLA, "Information Security Standards for the Procurement of Equipment and Services" R7 Edition Main Text (2025): https://www.mod.go.jp/atla/cybersecurity/01_kijun_0137_att_r07.pdf

• ATLA, "Information Security Standards for the Procurement of Equipment and Services FAQ" (October 2024): https://www.mod.go.jp/atla/cybersecurity/04_FAQ_2024oct.pdf

• ATLA, "Circular on Guidelines for Conducting Information Security Audits in the Procurement of Equipment and Services" ATLA (Adm) No. 4210 (2025): https://www.mod.go.jp/atla/cybersecurity/03_tsuchi_4210_r070617.pdf

• ATLA, "Circular on Guidelines for Measures Upon Receiving Reports from Defense-Related Companies Based on Information Security Standards" ATLA (Adm) No. 4239 (2025): https://www.mod.go.jp/atla/cybersecurity/03_tsuchi_4239_r070617.pdf

• IPA, "Top 10 Information Security Threats 2026" (2026): https://www.ipa.go.jp/security/10threats/10threats2026.html