Introduction: ISMAP and Japan's Cloud Assurance Regime
The Information system Security Management and Assessment Program, universally abbreviated as ISMAP (pronounced "iss-map"), is the Government of Japan's mandatory security assessment and registration scheme for cloud service providers that wish to supply cloud services to Japanese government agencies. Launched in 2020 and operated under the joint governance of the Cabinet Office, the Digital Agency (Digital-cho), the Ministry of Internal Affairs and Communications (MIC) and the Ministry of Economy, Trade and Industry (METI), ISMAP establishes a single, government-recognised baseline of security controls that a cloud service must demonstrably satisfy before it may be procured under the "cloud by default" principle of Japanese public-sector digital policy.
ISMAP is best understood as Japan's functional analogue to the United States FedRAMP programme: a centralised list (the ISMAP Cloud Service List) of pre-assessed, government-approved cloud services, backed by a rigorous third-party assessment methodology, a standardised control catalogue, and a steering committee that maintains the register. For any cloud service provider (CSP) with ambitions in the Japanese government market, ISMAP registration is not optional marketing collateral; it is the gate through which procurement flows. This guide is written for two audiences simultaneously: the auditor or assessment body practitioner who must plan and execute an ISMAP assessment, and the CISO, cloud security lead or governance-risk-and-compliance (GRC) team inside a CSP who must build, evidence and maintain the required control environment.
Throughout this deep-dive we adopt British/Indian English conventions and reference the real structure of the ISMAP standards as published by the ISMAP Steering Committee, including the ISMAP Management Standards, the ISMAP Standard for Security Requirements for Cloud Services, and the ISMAP-LOW variant for low-risk cloud services. All narrative, tables and checklists below are original interpretive guidance produced by CyberSigma's audit practice; we do not reproduce the copyrighted text of the ISMAP standards themselves.
Copyright and source note
ISMAP standards, control catalogues and the Cloud Service List are published by the ISMAP Steering Committee and the Digital Agency, Government of Japan, and are protected by copyright. Control identifiers, domain names and structural references in this guide are used descriptively for educational purposes. Organisations must obtain and rely upon the authoritative Japanese-language standards (and official English references where provided) for any actual assessment. This guide is CyberSigma's original analytical commentary and must not be treated as a substitute for the official ISMAP documentation.
What is ISMAP
ISMAP is a government-run assurance programme that assesses and registers cloud services against a defined set of security requirements so that Japanese government bodies can procure cloud with confidence. Its purpose is to raise the security baseline of cloud services used by the public sector, to reduce the assessment burden on individual procuring agencies by centralising the security due-diligence, and to give CSPs a single, predictable set of requirements to meet rather than a patchwork of agency-specific demands.
The programme rests on three foundational pillars. First, a standardised control catalogue derived from and harmonised with international standards, principally ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27017 (cloud-specific controls) and the U.S. NIST SP 800-53 control families, adapted to the Japanese government context and its own Common Standards for Information Security Measures for Government Agencies. Second, an independent third-party assessment model in which registered ISMAP assessment bodies (audit firms accredited to perform ISMAP work) evaluate the CSP against the requirements and produce an assessment report. Third, a central registration and maintenance mechanism operated by the ISMAP Steering Committee, which reviews assessment results and publishes qualifying services on the ISMAP Cloud Service List, subject to annual renewal.
ISMAP distinguishes between two registration tracks. The full ISMAP track applies to cloud services handling government information at standard risk levels. The ISMAP-LOW track, introduced later, provides a lighter-weight assessment for SaaS services that handle only low-impact information (broadly, information whose compromise would cause limited harm), reducing the control count and assessment effort while preserving core assurance. Selection of the correct track is one of the first material scoping decisions in any ISMAP engagement.
Registration is time-bounded. A service listed on the ISMAP Cloud Service List must undergo periodic re-assessment (annually) to remain listed; lapsed or withdrawn services are removed, which directly affects their eligibility for continued government procurement. This creates an ongoing compliance obligation, not a one-off certification event.
Who Must Comply and Scope of Applicability
ISMAP applies, in practice, to any cloud service provider seeking to sell cloud services into the Japanese central government and, increasingly by policy influence, to independent administrative agencies and parts of the wider public sector. Procuring agencies are directed to select cloud services from the ISMAP Cloud Service List as a matter of policy; a service that is not registered is at a structural disadvantage or is effectively excluded from procurement for in-scope information systems.
| Party | Applicability and obligation |
|---|
| Cloud service providers (IaaS/PaaS/SaaS) | Must undergo ISMAP (or ISMAP-LOW) assessment and achieve registration on the Cloud Service List to be eligible for in-scope government procurement; must maintain controls and renew annually. |
| Japanese government agencies (procuring bodies) | Directed under cloud-by-default policy to procure cloud services from the ISMAP Cloud Service List for information systems handling government information at the relevant risk level. |
| Independent administrative agencies / incorporated administrative agencies | Increasingly expected to align procurement with ISMAP-registered services, per government security policy diffusion. |
| Subcontractors and sub-service organisations | Where a registered CSP relies on underlying infrastructure or third parties, those dependencies fall within assessment scope and must be evidenced (carve-in / inclusive scoping). |
| Assessment bodies | Accredited audit firms that must operate to ISMAP assessment methodology and independence rules to produce valid assessment reports. |
Scope of applicability for a given CSP is defined by the specific cloud service (and its service model) being registered, the categories of government information it will process, store or transmit, and the deployment boundary (data centres, regions, management planes and supporting corporate functions). A CSP may register one service while leaving others out of scope; each registration is service-specific, not company-wide. Determining the correct assessment boundary, the information impact level, and whether ISMAP or ISMAP-LOW applies is therefore the decisive first step.
Structure of ISMAP
ISMAP is not a single monolithic document but a layered framework of management standards, security-requirement standards and supporting guidance. The management layer governs how a CSP runs its information security management system (ISMS-like governance, mirroring ISO/IEC 27001 clauses). The security-requirement layer specifies the technical and organisational controls (harmonised with ISO/IEC 27002, 27017 and NIST SP 800-53 families). The assessment layer defines methodology, reporting and the registration lifecycle.
| Layer / component | Purpose and content |
|---|
| ISMAP Management Standards | Define the governance system the CSP must operate: leadership, risk management, planning, resourcing, operation, performance evaluation and continual improvement (analogous to ISO/IEC 27001 management clauses 4-10). |
| ISMAP Standard for Security Requirements for Cloud Services | The core control catalogue: organisational, human, physical, technical and cloud-specific controls the service must implement and evidence. |
| Governance and risk-management requirements | Requirements for information security governance, risk assessment and treatment, supplier and subcontractor management, and compliance. |
| Cloud-specific control extensions | Controls addressing multi-tenancy isolation, virtualisation, shared-responsibility clarity, cloud administrative interfaces, data location and jurisdiction (ISO/IEC 27017-aligned). |
| ISMAP-LOW standard | Reduced control set for SaaS handling only low-impact information; streamlined assessment path. |
| Assessment methodology and reporting standard | How assessment bodies plan, sample, test, and report; evidence and independence requirements; the assessment report format. |
| Registration and maintenance rules | Steering Committee review, Cloud Service List publication, annual re-assessment, change management and de-listing. |
The control catalogue itself is organised into control domains/families that broadly parallel the internationally recognised structure. The following table summarises the principal control families a CSP must satisfy. These map closely to ISO/IEC 27002 control themes and NIST SP 800-53 families, which is deliberate: ISMAP was designed for international interoperability so that CSPs already holding ISO 27001/27017 or FedRAMP evidence can leverage it.
| Control family / domain | Illustrative scope |
|---|
| Governance & organisation of information security | Policies, roles, responsibilities, segregation of duties, management commitment, project security. |
| Human resource security | Screening, terms of employment, awareness/training, disciplinary process, termination and change of duties. |
| Asset & information management | Asset inventory, ownership, acceptable use, classification, labelling, media handling and disposal. |
| Access control & identity management | Access policy, user provisioning/de-provisioning, privileged access, authentication (incl. MFA), password and secret management, session control. |
| Cryptography | Cryptographic policy, key management lifecycle, encryption in transit and at rest, algorithm selection. |
| Physical & environmental security | Secure areas, data-centre perimeter, equipment protection, power/cooling, cabling, secure disposal. |
| Operations security | Change management, capacity management, malware protection, backup, logging and monitoring, clock synchronisation, vulnerability management, patching. |
| Communications & network security | Network segregation, boundary protection, transfer policies, secure messaging, service-provider network controls. |
| System acquisition, development & maintenance | Secure development lifecycle, security in requirements, test data protection, change control, outsourced development. |
| Supplier & subcontractor management | Supplier security agreements, cloud supply-chain risk, monitoring of subcontractors, ICT supply-chain controls. |
| Incident management | Detection, reporting, response, evidence collection, lessons learned, notification obligations. |
| Business continuity & resilience | Continuity planning, redundancy, ICT readiness for continuity, testing, recovery objectives. |
| Compliance & audit | Legal/regulatory compliance, intellectual property, records protection, privacy, independent review, technical compliance. |
| Cloud-specific controls | Tenant isolation, shared-responsibility definition, administrative-interface protection, virtualisation security, data location/jurisdiction, tenant data return and deletion. |
Master Assessment Checklist
This is the operational heart of the guide. Below, each control family is expanded with the specific matters an ISMAP assessor must verify and the typical evidence a CSP should be prepared to produce. Nothing in the catalogue is omitted; every family from the structure table above is enumerated. Assessors should treat each row as a test objective; implementers should treat each row as a build-and-evidence requirement. Where ISMAP-LOW applies, some depth reduces, but the domains remain the same.
Governance & Organisation of Information Security
| What to verify | Typical evidence |
|---|
| Approved information security policy set exists, is version-controlled and communicated | Signed policy documents, approval records, distribution/acknowledgement logs, intranet publication |
| Security roles, responsibilities and authorities are defined and assigned | Org chart, RACI matrix, role descriptions, appointment letters for CISO/security lead |
| Segregation of duties reduces opportunity for unauthorised/unintentional modification | SoD matrix, conflicting-access analysis, compensating-control descriptions |
| Management demonstrates commitment and reviews security performance | Management review minutes, security steering-committee records, KPI dashboards |
| Information security is addressed in project and change management | Project security checklists, gate-review records, security sign-offs |
| Contact with authorities and special-interest groups is maintained | Contact register, threat-intelligence subscriptions, CERT liaison records |
Human Resource Security
| What to verify | Typical evidence |
|---|
| Background verification is performed proportionate to role sensitivity | Screening policy, sample screening records, third-party check reports |
| Employment terms include security and confidentiality obligations | Signed contracts/NDAs, terms-of-employment clauses |
| Ongoing security awareness and role-specific training is delivered | Training curriculum, completion records, phishing-simulation results |
| Disciplinary process for security breaches is defined and applied | Disciplinary policy, sanitised case records |
| Termination/role-change revokes access and recovers assets | Leaver checklists, access-revocation tickets, asset-return logs |
Asset & Information Management
| What to verify | Typical evidence |
|---|
| A complete asset inventory with owners exists and is maintained | CMDB/asset register export, ownership assignments, last-review dates |
| Acceptable-use rules for assets are defined and enforced | Acceptable-use policy, acknowledgement records |
| Information is classified and labelled per a defined scheme | Classification policy, sample labelled data, data-map |
| Media handling, transport and disposal are controlled | Media-handling procedure, secure-disposal certificates, chain-of-custody |
| Removable media and end-point data are governed | DLP/endpoint policy, removable-media controls configuration |
Access Control & Identity Management
| What to verify | Typical evidence |
|---|
| Access-control policy enforces least privilege and need-to-know | Access-control policy, entitlement model, role definitions |
| User registration/de-registration and periodic access review occur | Joiner-mover-leaver tickets, quarterly access-recertification reports |
| Privileged access is restricted, logged and time-bound | PAM configuration, break-glass procedure, privileged-session logs |
| Strong authentication including MFA protects administrative and user access | IdP/MFA policy, enrolment reports, SSO configuration |
| Secrets, passwords and keys are managed securely | Secrets-vault configuration, password-policy settings, rotation records |
| Session management, timeout and remote-access controls are enforced | VPN/ZTNA configuration, session-timeout settings, bastion logs |
Cryptography
| What to verify | Typical evidence |
|---|
| Cryptographic policy defines approved algorithms and use cases | Crypto policy, approved-algorithm list (e.g. CRYPTREC-aligned) |
| Data is encrypted in transit using strong protocols | TLS configuration, cipher-suite scan results, certificate inventory |
| Data is encrypted at rest where required | Storage-encryption settings, KMS configuration |
| Key management covers generation, storage, rotation, revocation and destruction | KMS/HSM policy, key-lifecycle logs, key-custodian records |
Physical & Environmental Security
| What to verify | Typical evidence |
|---|
| Data-centre perimeter and secure areas restrict physical access | Facility access policy, badge logs, CCTV coverage evidence |
| Equipment is protected from environmental and power threats | UPS/generator records, cooling monitoring, fire-suppression certificates |
| Cabling and utilities are protected against interception/damage | Cabling diagrams, secured-room evidence |
| Secure equipment disposal and re-use is controlled | Disposal certificates, sanitisation records |
| Third-party data-centre controls are inherited and evidenced | Data-centre provider audit reports (e.g. ISO 27001/SOC 2), attestation letters |
Operations Security
| What to verify | Typical evidence |
|---|
| Documented operating procedures and change management are followed | Runbooks, change-advisory-board records, change tickets |
| Malware protection is deployed and current | EDR/AV configuration, signature/update reports |
| Backups are performed, protected and restore-tested | Backup schedule, restore-test reports, retention policy |
| Logging captures security-relevant events and is protected | Log-source inventory, SIEM configuration, log-integrity controls |
| Clocks are synchronised across systems | NTP configuration, time-source records |
| Vulnerability management and timely patching are operating | Vulnerability-scan reports, patch-SLA metrics, remediation tickets |
| Capacity is monitored to sustain availability | Capacity dashboards, threshold-alert configuration |
Communications & Network Security
| What to verify | Typical evidence |
|---|
| Networks are segmented and boundary protection is enforced | Network diagrams, firewall rule-base review, segmentation evidence |
| Tenant/management traffic is isolated | VLAN/VPC configuration, tenant-isolation test results |
| Secure transfer policies govern information exchange | Data-transfer policy, secure-file-transfer configuration |
| Network security is monitored for intrusions | IDS/IPS configuration, network-monitoring alerts |
| Wireless and remote connectivity are controlled | Wireless policy, remote-access architecture |
System Acquisition, Development & Maintenance
| What to verify | Typical evidence |
|---|
| Security requirements are defined for new/changed systems | Security requirement specs, threat models, design reviews |
| Secure development lifecycle and secure coding are practised | SDLC policy, code-review records, SAST/DAST results |
| Test data is protected and production data is not exposed in test | Data-masking evidence, environment-separation controls |
| Change control governs production deployments | Deployment pipeline controls, approval gates, rollback plans |
| Outsourced development is supervised and its output verified | Supplier development agreements, acceptance-test records |
Supplier & Subcontractor Management
| What to verify | Typical evidence |
|---|
| Supplier security requirements are defined in agreements | Supplier contracts, security schedules, DPAs |
| Cloud supply-chain and ICT supply-chain risk is assessed | Supply-chain risk register, supplier risk assessments |
| Subcontractor security is monitored throughout the relationship | Supplier review minutes, right-to-audit clauses, monitoring reports |
| Sub-service organisations relied upon are evidenced (carve-in) | Sub-service attestations, inherited-control mapping |
| Changes to supplier services are risk-managed | Supplier change-notification records |
Incident Management
| What to verify | Typical evidence |
|---|
| A documented incident-response plan defines roles and severities | IR plan/playbooks, severity matrix, contact tree |
| Events are detected, triaged and escalated | SIEM alerts, ticketing records, escalation logs |
| Evidence is collected and preserved for investigation | Forensic procedures, chain-of-custody records |
| Notification and reporting obligations (incl. to affected government customers) are met | Notification procedure, sample breach-notification records |
| Post-incident review drives corrective action | Post-incident reports, lessons-learned actions, closure records |
Business Continuity & Resilience
| What to verify | Typical evidence |
|---|
| Business-continuity and ICT-continuity plans exist with defined RTO/RPO | BCP/DR plans, RTO/RPO definitions, business-impact analysis |
| Redundancy and failover are architected for critical services | Architecture diagrams, availability-zone/region design |
| Continuity and recovery are tested periodically | DR-test reports, tabletop-exercise records, test results |
| Continuity dependencies on suppliers are covered | Supplier continuity commitments, escrow arrangements |
Compliance & Audit
| What to verify | Typical evidence |
|---|
| Legal, regulatory and contractual requirements are identified and met | Compliance register, legal-requirement mapping |
| Personal-data/privacy obligations (APPI) are honoured | Privacy policy, data-processing records, consent/notification evidence |
| Records are protected against loss and unauthorised access | Records-retention schedule, protection controls |
| Independent review of information security is conducted | Internal-audit reports, prior assessment reports |
| Technical compliance is verified (config, hardening) | Configuration-baseline reports, hardening-scan results |
Cloud-Specific Controls
| What to verify | Typical evidence |
|---|
| Multi-tenant isolation prevents cross-tenant data access | Isolation architecture, penetration-test results, tenant-separation tests |
| Shared-responsibility model is clearly documented for customers | Shared-responsibility matrix, customer-facing security documentation |
| Cloud administrative/management interfaces are hardened and monitored | Admin-portal MFA, API-security controls, admin-activity logs |
| Virtualisation/hypervisor security is maintained | Hypervisor hardening evidence, patch records, VM-escape testing |
| Data location, residency and jurisdiction are transparent and controlled | Data-location documentation, region configuration, data-flow maps |
| Tenant data return and secure deletion on exit are guaranteed | Data-return/deletion procedures, deletion-certificate templates |
Scoping and Materiality / Tiering
Scoping decisions determine cost, timeline and, ultimately, whether the registration will be accepted. The first determination is track selection: full ISMAP versus ISMAP-LOW. ISMAP-LOW is available only for SaaS services that handle low-impact government information; if the service handles information whose compromise could cause more than limited harm, the full ISMAP track applies. The second determination is the assessment boundary: which components (application, platform, infrastructure, management plane, corporate support functions and data centres) are inside the boundary, and which underlying services are inherited from a sub-service provider and must be carved in with evidence.
| Scoping dimension | Consideration |
|---|
| Service model | IaaS, PaaS or SaaS determines which controls the CSP owns versus inherits, and shapes the shared-responsibility matrix. |
| Information impact level | Low-impact information may qualify for ISMAP-LOW; standard-impact information requires the full ISMAP track. |
| Assessment boundary | Define the technical and organisational perimeter: regions, data centres, management planes, supporting business processes. |
| Inherited / sub-service controls | Underlying IaaS or third-party controls must be evidenced via attestations and mapped as inherited controls (carve-in). |
| Data residency | Whether data remains in Japan or is processed offshore affects control expectations and government acceptability. |
| Change frequency | High-change services require stronger change-management evidence and may face closer scrutiny at annual renewal. |
Implementation Approach
A first-time ISMAP registration is best delivered as a phased programme. The following phases move a CSP from readiness assessment to sustained maintenance. Each phase lists key activities and the deliverables that must exist before the phase gate is passed.
Phase 1 — Readiness and Gap Assessment
- Activities: confirm target service and track (ISMAP vs ISMAP-LOW), define provisional scope and boundary, map existing certifications (ISO 27001/27017, SOC 2, FedRAMP) to ISMAP controls, perform a control-by-control gap analysis.
- Deliverables: scope statement, control-mapping matrix, gap register with severity ratings, high-level remediation plan and budget.
Phase 2 — Remediation and Control Build
- Activities: close identified gaps across all control families, formalise policies and procedures, implement/tune technical controls (MFA, encryption, logging, isolation), stand up governance and management-review cadence.
- Deliverables: updated policy set, implemented control configurations, remediation-closure evidence, risk-treatment records.
Phase 3 — Evidence Preparation and Internal Pre-Assessment
- Activities: assemble the evidence library aligned to each control, run an internal pre-audit/mock assessment, validate the shared-responsibility matrix and inherited-control attestations.
- Deliverables: indexed evidence repository, internal pre-assessment report, corrective actions closed, assessment-readiness sign-off.
Phase 4 — Formal Assessment by an ISMAP Assessment Body
- Activities: engage an accredited assessment body, support fieldwork (interviews, sampling, testing), respond to findings and requests for information, remediate any noted deficiencies.
- Deliverables: assessment fieldwork completed, findings responses, assessment report produced by the assessment body.
Phase 5 — Registration and Steering-Committee Review
- Activities: submit the assessment results for Steering Committee review, respond to clarifications, achieve listing on the ISMAP Cloud Service List.
- Deliverables: registration application, review responses, confirmed Cloud Service List entry.
Phase 6 — Maintenance and Annual Re-Assessment
- Activities: operate controls continuously, manage significant changes, track metrics, prepare for and undergo annual re-assessment to retain listing.
- Deliverables: continuous-monitoring evidence, change records, annual re-assessment report, renewed listing.
Maturity / Capability and Tiering Model
ISMAP itself is a pass/register scheme rather than a graded maturity model, but experienced assessors and CISOs benefit from tracking control maturity to predict assessment outcomes and to prioritise investment. The following capability model, aligned to common maturity thinking, helps a CSP gauge readiness. Achieving registration broadly requires operating at Managed maturity or above across all control families.
| Maturity level | Description and ISMAP implication |
|---|
| Level 1 — Initial / Ad hoc | Controls informal and inconsistent. Not registration-ready; high risk of adverse findings. |
| Level 2 — Repeatable | Controls performed but reliant on individuals; limited documentation. Significant remediation needed before assessment. |
| Level 3 — Defined | Controls documented, standardised and communicated. Minimum baseline to begin serious assessment preparation. |
| Level 4 — Managed | Controls measured, monitored and evidenced with metrics. Typical level required to pass ISMAP assessment. |
| Level 5 — Optimising | Controls continuously improved with automation and analytics. Eases annual re-assessment and strengthens government confidence. |
Assessment and Audit Approach
An ISMAP assessment follows a structured, evidence-driven methodology executed by an accredited assessment body independent of the CSP. The following ordered steps describe the typical flow.
- Engagement and independence confirmation: appoint an accredited assessment body and confirm the absence of conflicts of interest.
- Scope and boundary agreement: finalise the service, track (ISMAP/ISMAP-LOW), assessment boundary and inherited controls.
- Assessment planning: build the audit plan, sampling approach, testing schedule and evidence requests.
- Documentation review: examine policies, procedures, architecture, prior certifications and the shared-responsibility matrix.
- Fieldwork and testing: conduct interviews, inspect configurations, observe processes and test technical controls.
- Findings evaluation: rate deficiencies, distinguish design versus operating-effectiveness gaps, and issue requests for remediation.
- Remediation and re-test: verify closure of findings and gather supplementary evidence.
- Assessment report production: the assessment body documents scope, methodology, results and conclusions.
- Steering Committee review and registration: submit results; on acceptance, the service is published on the Cloud Service List.
- Continuous monitoring and annual re-assessment: maintain evidence and repeat assessment annually to retain listing.
Evidence Request List
A well-organised evidence library is the single biggest determinant of a smooth assessment. Evidence should be categorised, indexed to controls, dated and owner-attributed. The following categorised list captures the artefacts assessors routinely request.
- Governance: information security policy set, risk assessment and treatment records, statement of applicability, management-review minutes, org chart and RACI.
- People: screening records, training completion and awareness metrics, signed NDAs, leaver checklists.
- Assets and data: asset inventory/CMDB, classification scheme, data-flow and data-location maps, media-disposal certificates.
- Access and identity: access-control policy, recertification reports, PAM/break-glass records, MFA enrolment reports.
- Cryptography: crypto policy, TLS/cipher scan results, KMS/HSM configuration and key-lifecycle logs.
- Physical: data-centre attestations (ISO 27001/SOC 2), badge and CCTV evidence, environmental-control records.
- Operations: change tickets, backup and restore-test reports, log-source inventory, SIEM configuration, vulnerability scans and patch metrics.
- Network: architecture and segmentation diagrams, firewall rule-base reviews, IDS/IPS configuration.
- Development: SDLC policy, code-review and SAST/DAST results, change-approval evidence.
- Suppliers: supplier contracts and security schedules, sub-service attestations, supply-chain risk register.
- Incident and continuity: IR plan and post-incident reports, BCP/DR plans, DR-test results, notification records.
- Compliance: APPI/privacy records, internal-audit reports, configuration-baseline and hardening evidence.
- Cloud-specific: tenant-isolation test results, shared-responsibility matrix, data-return/deletion procedures.
Roles and Responsibilities
| Role | Responsibility in the ISMAP programme |
|---|
| Executive sponsor / senior management | Owns the decision to pursue registration, provides resourcing, chairs management review, accepts residual risk. |
| CISO / information security lead | Owns the control environment, remediation programme and evidence quality; primary interface to the assessment body. |
| Cloud security / platform engineering | Implements and maintains technical controls (isolation, encryption, logging, hardening). |
| GRC / compliance team | Maintains the control-mapping matrix, evidence library, risk register and policy set; coordinates the audit. |
| Legal / privacy officer | Ensures APPI and contractual/regulatory compliance, manages DPAs and notification obligations. |
| Data-centre / infrastructure providers | Supply inherited controls and attestations for physical and environmental security. |
| ISMAP assessment body | Independently evaluates the service and produces the assessment report. |
| ISMAP Steering Committee | Reviews assessment results and maintains the Cloud Service List. |
KPIs and Metrics to Track
- Percentage of controls at Managed maturity or above across all families.
- Number and severity of open gaps/findings versus remediation-SLA compliance.
- Mean time to detect and mean time to respond for security incidents.
- Patch-SLA adherence and outstanding critical/high vulnerabilities.
- Access-recertification completion rate and count of orphaned/privileged accounts.
- MFA coverage across administrative and user access.
- Backup success rate and successful restore-test rate.
- DR-test pass rate against defined RTO/RPO.
- Percentage of suppliers/sub-services with current security attestations.
- Evidence-library freshness (proportion of artefacts within review cycle).
- Days remaining to annual re-assessment and readiness score.
Readiness Checklist
- Target service confirmed and correct track (ISMAP or ISMAP-LOW) selected.
- Assessment boundary and inherited/sub-service controls defined and documented.
- Existing certifications (ISO 27001/27017, SOC 2, FedRAMP) mapped to ISMAP controls.
- Full control-family gap analysis completed and gaps remediated.
- Policy set approved, versioned, communicated and acknowledged.
- MFA, encryption in transit and at rest, and key management implemented.
- Logging, monitoring, vulnerability management and patching operating with metrics.
- Tenant isolation validated by testing; shared-responsibility matrix published.
- Backup, restore-test, BCP/DR plans and DR-test results in place.
- Incident-response plan tested; notification procedures defined.
- Supplier and sub-service attestations current and mapped as inherited controls.
- APPI/privacy obligations addressed and evidenced.
- Evidence library indexed to controls, dated and owner-attributed.
- Internal pre-assessment/mock audit completed and findings closed.
- Accredited assessment body engaged and independence confirmed.
Common Gaps and Findings
- Incomplete or stale asset inventory that fails to reflect the true assessment boundary.
- Shared-responsibility matrix that is vague, leaving customer versus provider control ownership ambiguous.
- Weak evidence of tenant isolation testing for multi-tenant SaaS.
- Privileged access without adequate PAM, break-glass control or session logging.
- Inconsistent MFA coverage, particularly on administrative and API access paths.
- Backups performed but restore capability never tested against RTO/RPO.
- Sub-service/supplier reliance without current attestations or inherited-control mapping.
- Logging enabled but not centralised, monitored or protected against tampering.
- Change management bypassed for expedited or emergency deployments without after-the-fact review.
- APPI/privacy obligations under-evidenced, especially data-location and deletion assurances.
- Evidence library disorganised, undated or not indexed to specific controls, slowing fieldwork.
- Under-scoping ISMAP-LOW when the information impact level actually requires the full track.
ISMAP Mapped to Other Frameworks
ISMAP was deliberately harmonised with international standards, which lets CSPs reuse existing evidence. The mapping below is indicative and directional; it does not imply one-for-one equivalence, and each framework must still be satisfied on its own terms.
| ISMAP control area | Related framework reference |
|---|
| Management standards (governance, risk, improvement) | ISO/IEC 27001 clauses 4-10; NIST SP 800-53 PM family |
| Access control & identity | ISO/IEC 27002 access controls; NIST SP 800-53 AC and IA families |
| Cryptography | ISO/IEC 27002 cryptography; NIST SP 800-53 SC family; CRYPTREC guidance |
| Operations security (logging, patching, malware) | ISO/IEC 27002 operations controls; NIST SP 800-53 AU, SI, CM families |
| Incident management | ISO/IEC 27035; NIST SP 800-53 IR family |
| Business continuity & resilience | ISO 22301; NIST SP 800-53 CP family |
| Supplier & supply-chain security | ISO/IEC 27036; NIST SP 800-161; NIST SP 800-53 SR family |
| Cloud-specific controls | ISO/IEC 27017 and 27018; FedRAMP baselines; CSA CCM |
| Physical & environmental | ISO/IEC 27002 physical controls; NIST SP 800-53 PE family |
| Privacy / personal data | APPI (Japan); ISO/IEC 27701; GDPR (directionally) |
How CyberSigma helps
CyberSigma's cloud-assurance practice takes CSPs end-to-end through ISMAP: track selection and scoping, a full control-family gap assessment with reuse of existing ISO 27001/27017, SOC 2 and FedRAMP evidence, remediation programme management, evidence-library construction indexed to every control, internal pre-assessment (mock audit), coordination with the accredited assessment body, and ongoing readiness for the annual re-assessment that keeps you on the Cloud Service List. Whether you are pursuing full ISMAP or the lighter ISMAP-LOW track, our CERT-In empanelled and QSA-qualified auditors give you an accurate, defensible path to Japanese government eligibility. Contact CyberSigma to begin your ISMAP readiness assessment.
