Full Maturity Assessment Enablement Guide

Best for: Banks, insurance companies, financial services, payment processors

Emphasized domains: Data Sovereignty (2.0×), Assurance Sovereignty (2.0×), Operational Sovereignty (1.5×)

Rationale: Financial institutions face stringent regulatory requirements (PCI DSS, SOX, DORA) demanding strong data protection, audit controls, and business continuity.

Best for: Hospitals, health systems, medical research, healthcare technology

Emphasized domains: Data Sovereignty (2.0×), Operational Sovereignty (2.0×)

Rationale: Healthcare organizations must protect sensitive patient data (HIPAA, GDPR) while maintaining 24/7 operational resilience for patient safety.

Best for: Federal/state/local government, public sector, defense contractors

Emphasized domains: Data Sovereignty (2.0×), Assurance Sovereignty (2.0×), Executive Oversight (2.0×)

Rationale: Government entities handle sensitive citizen data and critical infrastructure with strict sovereignty requirements, transparency needs, and national security concerns.

Best for: Industrial manufacturing, automotive, aerospace, discrete manufacturing

Emphasized domains: Operational Sovereignty (2.0×), Managed Services (2.0×)

Rationale: Manufacturers prioritize production uptime, OT/IT integration, and IP protection for proprietary designs and processes.

Best for: Telecom providers, ISPs, mobile carriers, network infrastructure

Emphasized domains: Data Sovereignty (2.0×), Operational Sovereignty (2.0×), Assurance Sovereignty (2.0×)

Rationale: Telecom operators manage critical communications infrastructure with subscriber data protection requirements and strict regulatory compliance (NIS2).

Best for: Organizations without specific industry focus or those spanning multiple sectors

Emphasized domains: All domains equally weighted (1.0×)

Rationale: Provides an unbiased assessment across all domains without industry-specific emphasis.

Example: The CIO believes they have Level 4 disaster recovery, but the Operations Manager says they've never successfully tested it.

Response: "I'm hearing different perspectives here. Let's focus on what we can verify. [Operations Manager], can you describe your most recent DR test? [CIO], what metrics are you using to assess DR maturity? Based on industry best practices, regular testing is required for Level 4. Without test evidence, we should consider Level 2 or 3."

Approach: Stay neutral, ask for evidence, refer to maturity definitions, help them reach consensus based on facts.

Example: After several Level 1-2 scores, the CISO becomes defensive: "We have excellent security! This assessment is unfair!"

Response: "I appreciate your commitment to security. These scores reflect maturity along a journey—they're not a judgment of your team's effort or capability. Many excellent organizations score at Level 2-3 initially. The assessment helps us identify where focused investment will have the most impact. Would it help to review the scoring criteria together?"

Approach: Validate their feelings, emphasize growth mindset, reframe scores as opportunities, avoid blame.

Example: Multiple participants don't know the answer to questions about vendor contracts or key management.

Response: "That's valuable information in itself—if key stakeholders don't know, that typically indicates Level 1 or 2 maturity. Let's mark this for follow-up investigation and make a provisional rating of Level 1. You can update it later once you've verified."

Approach: Frame "don't know" as data, assign conservative rating, offer to revisit, ensure follow-up action item is captured.

What this measures: Whether the organization explicitly controls where data is stored based on legal requirements

Key questions to ask:

• "Do you have a written data residency policy?"
• "Can you show me which cloud regions your data is stored in?"
• "How do you prevent data from being accidentally stored outside approved regions?"
• "What happens if a cloud provider wants to move your data for operational reasons?"

Evidence to request: Data residency policy document, cloud provider contracts specifying regions, configuration screenshots showing geo-restrictions

Red flags: "We think it's in [region]", "The cloud provider handles that", "We haven't checked recently"

What this measures: Compliance with data protection regulations and implementation of privacy controls

Key questions to ask:

• "Which data protection regulations apply to you? (GDPR, CCPA, PIPL, etc.)"
• "How do you handle data subject rights requests (access, deletion, portability)?"
• "Do you have a Data Protection Officer or equivalent role?"
• "How are cross-border data transfers authorized and tracked?"

Evidence to request: Privacy policies, consent management systems, GDPR compliance documentation, Privacy Impact Assessments

Red flags: Confusion about applicable regulations, no defined process for data subject requests, relying solely on vendor certifications

What this measures: Whether the organization knows what data it has, where it is, and how sensitive it is

Key questions to ask:

• "Do you have a complete inventory of your data assets?"
• "What classification levels do you use? (Public, Internal, Confidential, Restricted)"
• "How do you discover and classify new data automatically?"
• "Who owns each data asset and is accountable for its protection?"

Evidence to request: Data inventory/catalog, classification framework document, data discovery tool demonstrations, data ownership registers

Red flags: "We're working on that", manual spreadsheet-based tracking, no data ownership assigned

What this measures: Ability to resist extra-territorial legal demands and maintain domestic legal control

Key questions to ask:

• "What jurisdiction's law governs your cloud contracts?"
• "How would you respond to a foreign government data access request?"
• "Do you have contractual provisions requiring vendors to notify you of legal demands?"
• "Have you assessed conflicts between foreign laws (CLOUD Act) and domestic requirements?"

Evidence to request: Vendor contracts showing governing law clauses, legal risk register, documented escalation procedures

Red flags: Contracts governed by foreign law, no notification provisions, unaware of jurisdictional conflicts

What this measures: Whether the organization exclusively controls encryption keys, independent of cloud providers

Key questions to ask:

• "Who generates and stores your encryption keys?"
• "Can your cloud provider access your encryption keys?"
• "Do you use HSMs (Hardware Security Modules)? Where are they located?"
• "How frequently do you rotate encryption keys?"
• "What would happen if your provider received a legal demand to decrypt your data?"

Evidence to request: Key management architecture diagrams, HSM procurement/contracts, key rotation policies, external key management (EKM) solution documentation

Red flags: Provider-managed keys, lack of HSMs, no key rotation schedule, unclear about who can access keys

Note: This is a 6-point question because key control is fundamental to data sovereignty. Organizations often struggle here.

What this measures: Protection of data during processing (data-in-use), not just storage and transit

Key questions to ask:

• "How do you protect data while it's being processed in memory?"
• "Are you using confidential computing or Trusted Execution Environments (TEEs)?"
• "Can cloud administrators access data in memory during processing?"
• "How do you ensure sensitive data isn't logged in plaintext?"

Evidence to request: Confidential computing implementations (Intel SGX, AMD SEV, AWS Nitro Enclaves), memory encryption configurations, log sanitization policies

Red flags: Unaware of data-in-use protection, relying only on at-rest and in-transit encryption, plaintext logging of sensitive data

Note: This is often Level 1-2 for most organizations; confidential computing is still emerging.

What this measures: Real-time monitoring and immutable logging of all data movements

Key questions to ask:

• "Can you show me where your data flows across systems?"
• "Do you have Data Loss Prevention (DLP) tools deployed?"
• "How do you monitor and prevent unauthorized data transfers?"
• "Are your audit logs immutable and stored sovereignly?"
• "How quickly can you detect an unauthorized cross-border data transfer?"

Evidence to request: Data flow maps, DLP dashboards, audit log retention policies, SIEM integration, transfer blocking evidence

Red flags: No data flow visibility, reactive rather than preventive controls, logs stored with cloud provider

What this measures: Strict, audited, and revocable control over vendor and partner access to data

Key questions to ask:

• "Which third parties have access to your data? Why?"
• "Do you use Just-in-Time (JIT) access for vendor support?"
• "How do you monitor and record third-party access sessions?"
• "Can you immediately revoke vendor access in an emergency?"
• "Where are vendor support personnel located geographically?"

Evidence to request: Third-party access policies, Privileged Access Management (PAM) systems, session recordings, vendor risk assessments

Red flags: Persistent vendor access, no session monitoring, vendors located in concerning jurisdictions, inability to quickly revoke access

Note: This is the highest point value question as third-party access is a primary sovereignty risk.

What this measures: The extent to which the organization controls its foundational technology components

Key questions to ask:

• "What percentage of your technology stack is open source vs. proprietary?"
• "Can you independently operate and troubleshoot your core systems without vendor support?"
• "Do you have internal expertise in the technologies running your critical infrastructure?"
• "Could you rebuild your infrastructure from scratch if needed?"

Evidence to request: Technology inventory, internal skills matrix, documentation of core systems

Red flags: Heavy reliance on proprietary systems, lack of internal technical expertise, "vendor handles everything" mentality

What this measures: Assessment and mitigation of vendor lock-in risks

Key questions to ask:

• "Have you assessed the effort required to switch to a different cloud provider?"
• "Do your contracts include data portability and exit assistance clauses?"
• "Are you using vendor-specific features that would be difficult to replace?"
• "Have you calculated the total cost of vendor lock-in?"

Evidence to request: Lock-in risk assessment, vendor contracts with exit clauses, list of vendor-specific dependencies

Red flags: No exit strategy, heavy use of proprietary APIs, contracts without portability provisions

What this measures: Use of industry-standard, non-proprietary technical frameworks

Key questions to ask:

• "Do you have a list of approved technical standards for new projects?"
• "Are you using industry-standard APIs and protocols?"
• "How do you ensure new systems follow non-proprietary standards?"
• "Can your systems interoperate with multiple vendors' products?"

Evidence to request: Technical standards documentation, API specifications, architecture review guidelines

Red flags: No standards policy, heavy reliance on vendor-specific APIs, systems that can't interoperate

What this measures: Ability to migrate workloads between platforms

Key questions to ask:

• "Can you migrate a workload between cloud providers within a defined timeframe?"
• "Are your applications containerized for portability?"
• "Do you use Infrastructure-as-Code for reproducible deployments?"
• "Have you tested migration procedures in a non-production environment?"

Evidence to request: Container adoption metrics, IaC repositories, migration test results

Red flags: No containerization strategy, manual infrastructure management, untested migration procedures

What this measures: Control over hardware supply chain and verification

Key questions to ask:

• "Do you know the origin and manufacturing location of your critical hardware?"
• "Do you verify hardware integrity before deployment (TPM, secure boot)?"
• "How do you validate firmware and hardware updates?"
• "Do you have supply chain attestation for critical components?"

Evidence to request: Hardware procurement policies, supply chain verification procedures, TPM/secure boot configurations

Red flags: No hardware provenance tracking, unverified firmware updates, no supply chain validation

What this measures: Direct control over application runtime environments

Key questions to ask:

• "Where are your critical applications hosted?"
• "Do you have direct administrative control over the runtime environment?"
• "Are you using self-hosted or sovereign-partner-hosted application servers?"
• "Can the cloud provider access or modify your application runtime?"

Evidence to request: Hosting architecture diagrams, administrative access controls, runtime configuration

Red flags: Fully managed PaaS with no underlying access, provider-controlled runtimes, limited administrative rights

What this measures: Ownership and control of source code and intellectual property

Key questions to ask:

• "Do you own all custom application source code?"
• "Where is your source code version control system hosted?"
• "Do you have code escrow arrangements for vendor-developed software?"
• "Are IP ownership rights clearly defined in all development contracts?"

Evidence to request: Source code repository locations, code escrow agreements, development contracts with IP clauses

Red flags: Vendor-owned custom code, third-party hosted version control, unclear IP ownership

What this measures: Strategic planning to address sovereignty risks in technology evolution

Key questions to ask:

• "Do you have a 3-5 year technology roadmap addressing sovereignty risks?"
• "Have you identified high-risk technology dependencies?"
• "Are you planning to replace proprietary components with sovereign alternatives?"
• "How do you evaluate new technologies for sovereignty compliance?"

Evidence to request: Technology roadmap documents, dependency risk register, sovereignty evaluation criteria

Red flags: No long-term planning, reactive approach to sovereignty, no evaluation framework for new tech

What this measures: Documentation of critical operational procedures for independence

Key questions to ask:

• "Are all critical operational procedures documented?"
• "Can your team execute operations without vendor documentation?"
• "Where are operational runbooks stored?"
• "How often are operational procedures reviewed and updated?"

Evidence to request: Operational runbooks, procedure documentation, documentation update logs

Red flags: Reliance on vendor documentation, undocumented critical procedures, tribal knowledge

What this measures: Internal operational capability vs. external dependencies

Key questions to ask:

• "Do you have internal staff capable of performing all critical operations?"
• "What percentage of operations require vendor involvement?"
• "Have you identified skills gaps in your operations team?"
• "Do you have training programs for sovereign operations?"

Evidence to request: Skills matrix, training programs, vendor dependency assessment

Red flags: Heavy vendor dependency, no internal capability, no skills development program

What this measures: Operational resilience and recovery capabilities

Key questions to ask:

• "Can you recover operations without vendor assistance?"
• "Are disaster recovery plans tested regularly?"
• "Do backup systems reside in sovereign infrastructure?"
• "Can you maintain operations during a vendor outage?"

Evidence to request: DR test results, backup infrastructure documentation, continuity plans

Red flags: Untested DR plans, backup dependency on same vendor, no failover capability

What this measures: Control over incident response processes

Key questions to ask:

• "Do you control incident response processes end-to-end?"
• "Can you investigate security incidents without vendor access to logs?"
• "Where are security logs stored?"
• "Do you have an internal Security Operations Center (SOC)?"

Evidence to request: Incident response playbooks, SOC operations, log management infrastructure

Red flags: Vendor-controlled incident response, logs only accessible via vendor, no internal SOC

What this measures: Control over deployment processes

Key questions to ask:

• "Who manages your production deployment processes?"
• "Can you deploy updates without vendor involvement?"
• "Do you control CI/CD pipelines independently?"
• "Where are deployment automation tools hosted?"

Evidence to request: CI/CD pipeline architecture, deployment automation tools, release management processes

Red flags: Vendor-managed deployments, external CI/CD platforms, no automated deployment capability

What this measures: Operational continuity through staff development

Key questions to ask:

• "How quickly can you onboard new operational staff?"
• "Do you have succession planning for critical operational roles?"
• "Are operational skills concentrated with specific individuals?"
• "Do you cross-train team members on critical functions?"

Evidence to request: Succession plans, cross-training programs, knowledge transfer documentation

Red flags: Single points of failure in staffing, no succession planning, concentrated expertise

What this measures: Independent infrastructure monitoring capability

Key questions to ask:

• "Do you control infrastructure monitoring tools?"
• "Where is operational telemetry data stored?"
• "Can you detect anomalies without vendor-provided tools?"
• "Do you have independent visibility into infrastructure health?"

Evidence to request: Monitoring tool architecture, telemetry data storage, alerting systems

Red flags: Vendor-provided monitoring only, no independent telemetry, limited visibility

What this measures: Ability to exit infrastructure and migrate workloads

Key questions to ask:

• "Can you exit your current infrastructure within a defined timeframe?"
• "Have you tested workload migration to alternative platforms?"
• "Do you have automated tools for infrastructure migration?"
• "What is your RTO (Recovery Time Objective) for a forced migration?"

Evidence to request: Migration test results, automated migration tools, documented RTO/RPO

Red flags: No exit strategy, untested migration, undefined RTO, manual migration processes

What this measures: Right and capability to audit service providers

Key questions to ask:

• "Do you have the right to audit your service providers?"
• "When was the last time you conducted a provider audit?"
• "Can you perform unannounced audits?"
• "Do you verify vendor compliance claims independently?"

Evidence to request: Audit rights in contracts, recent audit reports, audit schedules

Red flags: No audit rights, relying solely on vendor attestations, never conducted an audit

What this measures: Compliance framework implementation and verification

Key questions to ask:

• "Which compliance frameworks apply to your operations?"
• "Do you have current compliance certifications (ISO 27001, SOC 2, etc.)?"
• "How do you verify vendor compliance certifications?"
• "Can you demonstrate continuous compliance?"

Evidence to request: Compliance certifications, compliance monitoring systems, verification procedures

Red flags: Unclear compliance requirements, expired certifications, no verification process

What this measures: Control over security monitoring infrastructure

Key questions to ask:

• "Do you control security monitoring tools?"
• "Where are security logs aggregated and analyzed?"
• "Can you detect threats without vendor-provided visibility?"
• "Do you use sovereign-based security operations tools?"

Evidence to request: SIEM architecture, log aggregation infrastructure, monitoring tool ownership

Red flags: Vendor-controlled SIEM, logs not accessible independently, foreign-hosted security tools

What this measures: Infrastructure integrity verification capabilities

Key questions to ask:

• "How do you verify the integrity of your infrastructure?"
• "Do you have tamper-detection mechanisms in place?"
• "Can you detect unauthorized changes to your environment?"
• "Do you use cryptographic verification for system integrity?"

Evidence to request: Integrity monitoring systems, tamper detection tools, baseline configurations

Red flags: No integrity verification, unable to detect tampering, no baseline management

What this measures: Independent security testing and validation

Key questions to ask:

• "Do you conduct regular penetration testing?"
• "Are security assessments performed by independent third parties?"
• "How do you validate security controls effectiveness?"
• "Can you demonstrate security posture to regulators?"

Evidence to request: Penetration test reports, third-party assessment results, validation methodology

Red flags: No independent testing, relying on vendor testing only, unvalidated controls

What this measures: Compliance audit trail management

Key questions to ask:

• "Where are compliance audit trails stored?"
• "Are audit logs immutable and tamper-proof?"
• "Can you produce compliance evidence on demand?"
• "How long do you retain audit records?"

Evidence to request: Audit log infrastructure, immutability controls, retention policies

Red flags: Mutable audit logs, no retention policy, inability to produce evidence quickly

What this measures: Control plane security and monitoring

Key questions to ask:

• "Do you control access to the cloud management plane?"
• "Can you detect unauthorized control plane access?"
• "Are control plane activities continuously monitored?"
• "Do you have alerts for suspicious control plane operations?"

Evidence to request: Control plane access controls, monitoring configuration, alerting rules

Red flags: No control plane visibility, unmonitored access, no alerting for anomalies

What this measures: Tested capability to migrate due to assurance failures

Key questions to ask:

• "Have you tested migration to alternative providers?"
• "Do you have exit criteria that would trigger migration?"
• "Can you migrate critical workloads within your defined timeframe?"
• "Do you maintain automated migration playbooks?"

Evidence to request: Migration test results, exit criteria documentation, automated playbooks

Red flags: No tested migration capability, undefined exit criteria, manual migration only

What this measures: Strategic approach to open source software adoption

Key questions to ask:

• "What percentage of your stack uses open source software?"
• "Do you have a policy favoring open source adoption?"
• "Can you justify proprietary software choices?"
• "Have you evaluated open source alternatives for proprietary tools?"

Evidence to request: OSS adoption policy, software inventory showing OSS vs proprietary, justification process

Red flags: No OSS policy, default to proprietary solutions, no evaluation of alternatives

What this measures: Governance and tracking of open source components

Key questions to ask:

• "Do you have an OSS governance framework?"
• "How do you track open source components and their licenses?"
• "Do you have processes for OSS security vulnerability management?"
• "Can you identify all OSS dependencies in your applications?"

Evidence to request: OSS governance documentation, dependency tracking tools (SBOM), vulnerability scanning

Red flags: No OSS governance, unknown dependencies, no vulnerability tracking

What this measures: Active participation in open source communities

Key questions to ask:

• "Do you contribute code, documentation, or resources to OSS projects?"
• "Are developers encouraged to participate in OSS communities?"
• "Do you sponsor or support critical OSS projects you depend on?"
• "Have you open-sourced any internal tools or projects?"

Evidence to request: OSS contribution records, community participation metrics, sponsorship agreements

Red flags: No contributions, developers not allowed to participate, only consuming OSS

What this measures: Internal capability to support critical OSS

Key questions to ask:

• "Do you have internal expertise to support critical OSS components?"
• "Can you fork and maintain OSS projects if needed?"
• "Do you have developers skilled in the OSS technologies you use?"
• "Can you provide emergency support for OSS issues?"

Evidence to request: Skills matrix for OSS technologies, fork capability demonstration, support procedures

Red flags: No internal OSS expertise, unable to support critical components, total reliance on community

What this measures: OSS security and vulnerability management

Key questions to ask:

• "How do you monitor OSS security advisories?"
• "Do you have a process for patching OSS vulnerabilities?"
• "Can you assess OSS security independently?"
• "Do you perform security scanning of OSS components?"

Evidence to request: Vulnerability monitoring systems, patching processes, security scanning tools

Red flags: No security monitoring for OSS, reactive patching only, no scanning capability

What this measures: Assessment of OSS project health and sustainability

Key questions to ask:

• "Have you evaluated the maturity and sustainability of OSS projects you depend on?"
• "Do you assess OSS project governance and community health?"
• "What happens if a critical OSS project becomes unmaintained?"
• "Do you have contingency plans for OSS project failures?"

Evidence to request: Project health assessments, sustainability criteria, contingency plans

Red flags: No project assessment, dependency on unmaintained projects, no contingency planning

What this measures: OSS supply chain security

Key questions to ask:

• "Do you verify the integrity and provenance of OSS components?"
• "Do you use signed releases and verify signatures?"
• "Can you trace OSS components back to official sources?"
• "Do you protect against OSS supply chain attacks?"

Evidence to request: Signature verification processes, provenance tracking, supply chain security controls

Red flags: No signature verification, unverified sources, no supply chain security

What this measures: Strategic use of OSS for sovereignty goals

Key questions to ask:

• "Do you leverage OSS for strategic sovereignty goals?"
• "Have you replaced proprietary tools with OSS alternatives?"
• "Is OSS adoption part of your sovereignty roadmap?"
• "How do you measure the sovereignty benefits of OSS?"

Evidence to request: Sovereignty roadmap showing OSS initiatives, replacement projects, metrics

Red flags: No strategic OSS approach, no measurable sovereignty benefits, OSS not in roadmap

What this measures: Executive and board-level awareness of sovereignty

Key questions to ask:

• "Is digital sovereignty on the board's risk agenda?"
• "Do executives understand sovereignty risks and opportunities?"
• "Is there a designated executive owner for sovereignty?"
• "How often is sovereignty discussed at the executive level?"

Evidence to request: Board meeting agendas, executive sponsor designation, governance documentation

Red flags: No board discussion, no executive ownership, sovereignty relegated to IT only

What this measures: Formal sovereignty strategy and alignment

Key questions to ask:

• "Do you have a formal digital sovereignty strategy?"
• "Is the strategy aligned with business objectives?"
• "Does the strategy include measurable goals and timelines?"
• "Is the strategy reviewed and updated regularly?"

Evidence to request: Sovereignty strategy document, goals and metrics, review schedules

Red flags: No formal strategy, unclear goals, no alignment with business objectives

What this measures: Financial commitment to sovereignty

Key questions to ask:

• "Is there dedicated budget for sovereignty initiatives?"
• "How much are you investing in sovereignty improvements?"
• "Are sovereignty costs tracked separately?"
• "Do you measure ROI on sovereignty investments?"

Evidence to request: Budget allocation, investment tracking, ROI measurements

Red flags: No dedicated budget, costs buried in general IT spend, no ROI tracking

What this measures: Sovereignty maturity tracking and KPIs

Key questions to ask:

• "How do you track sovereignty maturity over time?"
• "Do you have KPIs for sovereignty progress?"
• "Are sovereignty metrics reported to executives?"
• "How do you benchmark against industry peers?"

Evidence to request: KPI dashboards, tracking systems, benchmark reports

Red flags: No tracking, no defined KPIs, no benchmarking

What this measures: Sovereignty integration into procurement

Key questions to ask:

• "Is sovereignty integrated into procurement processes?"
• "Do vendor selection criteria include sovereignty requirements?"
• "Are contracts reviewed for sovereignty compliance?"
• "Do you negotiate sovereignty terms with vendors?"

Evidence to request: Procurement policies, vendor selection criteria, contract templates

Red flags: No sovereignty in procurement, standard vendor contracts accepted, no negotiation

What this measures: Employee awareness and training

Key questions to ask:

• "Do employees understand sovereignty requirements?"
• "Is sovereignty training provided to relevant staff?"
• "Is sovereignty awareness part of onboarding?"
• "How do you promote a culture of sovereignty?"

Evidence to request: Training programs, onboarding materials, awareness campaigns

Red flags: No training, employees unaware, sovereignty not in culture

What this measures: Regulatory engagement and awareness

Key questions to ask:

• "Do you engage with regulators on sovereignty topics?"
• "Are you monitoring regulatory developments?"
• "Do you participate in industry sovereignty initiatives?"
• "How do you stay ahead of sovereignty regulations?"

Evidence to request: Regulatory engagement records, monitoring systems, industry participation

Red flags: No regulatory engagement, reactive to regulations, no industry participation

What this measures: External communication of sovereignty posture

Key questions to ask:

• "Do you communicate sovereignty posture to stakeholders?"
• "Is sovereignty part of customer value propositions?"
• "How do you demonstrate sovereignty to clients?"
• "Do you publish sovereignty commitments publicly?"

Evidence to request: Public commitments, customer materials, stakeholder communications

Red flags: No external communication, sovereignty not mentioned to customers, no public commitments

What this measures: Inventory and classification of managed service providers

Key questions to ask:

• "Do you have an inventory of all managed service providers?"
• "What critical functions are outsourced?"
• "Do you understand the sovereignty implications of each service?"
• "Have you classified managed services by sovereignty risk?"

Evidence to request: MSP inventory, outsourced functions list, risk classifications

Red flags: No MSP inventory, unknown sovereignty risks, unclassified services

What this measures: Contractual data ownership and portability

Key questions to ask:

• "Do contracts define data ownership unambiguously?"
• "Can you access and export your data at any time?"
• "Do you retain control over encryption keys?"
• "Are data portability rights contractually guaranteed?"

Evidence to request: MSP contracts showing data ownership clauses, portability provisions

Red flags: Ambiguous ownership, limited data access, vendor-controlled keys, no portability guarantee

What this measures: Geographic and jurisdictional control of MSPs

Key questions to ask:

• "Where are managed service providers located?"
• "What is the legal jurisdiction governing service contracts?"
• "Are service personnel located in trusted jurisdictions?"
• "Can providers access your data from foreign locations?"

Evidence to request: Provider locations, contract governing law, personnel jurisdiction documentation

Red flags: Foreign-based providers, foreign jurisdiction contracts, unrestricted access locations

What this measures: Exit planning and transition capabilities

Key questions to ask:

• "Do contracts include service exit and transition assistance?"
• "How long would it take to migrate from a managed service?"
• "Have you tested exit procedures?"
• "Do you have alternatives identified for critical managed services?"

Evidence to request: Exit clauses in contracts, transition plans, alternative provider evaluations

Red flags: No exit provisions, undefined transition time, untested procedures, no alternatives

What this measures: Visibility into managed service operations

Key questions to ask:

• "Do you have visibility into managed service operations?"
• "Can you audit provider activities independently?"
• "Do you receive detailed operational logs?"
• "Can you detect provider security incidents?"

Evidence to request: Audit capabilities, operational logs access, monitoring dashboards

Red flags: No visibility, unable to audit, limited logging, no incident detection

What this measures: Service level agreements and accountability

Key questions to ask:

• "Do contracts define SLAs and penalties clearly?"
• "Are sovereignty requirements included in SLAs?"
• "How do you monitor SLA compliance?"
• "What recourse do you have for SLA violations?"

Evidence to request: SLA documentation, sovereignty requirements in contracts, compliance monitoring

Red flags: Weak SLAs, no sovereignty requirements, no monitoring, limited recourse

What this measures: Provider security and compliance verification

Key questions to ask:

• "Have you verified provider security certifications?"
• "Do you conduct regular provider risk assessments?"
• "Are providers subject to the same security requirements as internal teams?"
• "How do you ensure provider compliance with your standards?"

Evidence to request: Provider certifications, risk assessment reports, security requirements

Red flags: Unverified certifications, no risk assessments, different standards for providers

What this measures: Multi-provider strategy for resilience

Key questions to ask:

• "Do you use multiple providers to avoid dependency on a single vendor?"
• "Can critical services failover to alternative providers?"
• "Have you tested multi-provider resilience?"
• "Do you have geographic diversity in service providers?"

Evidence to request: Multi-provider architecture, failover tests, geographic distribution

Red flags: Single provider dependency, no failover capability, untested resilience, no geographic diversity

Behavior: Claims high maturity without evidence, dismisses concerns, believes "we have the best security"

Approach: Acknowledge their confidence, then request specific evidence. Use data and industry benchmarks. Ask their technical team to verify claims. Frame lower scores as "industry-standard journey" rather than failures.

Behavior: Late to session, distracted, checking phone, wants to rush through

Approach: Respectfully emphasize the value of their time investment. Show early results to demonstrate value. Offer to reschedule if they can't focus. Break into shorter sessions if needed.

Behavior: Takes low scores personally, explains why gaps aren't their fault, blames budget/management

Approach: Emphasize this is organizational assessment, not personal evaluation. Validate resource constraints. Position results as ammunition for budget requests. Frame gaps as opportunities to demonstrate need for investment.

Behavior: Debates every nuance, wants to discuss technical details extensively, struggles to choose between maturity levels

Approach: Appreciate their thoroughness. Set time limits for each question. Offer to deep-dive on specific topics afterward. Remind that perfect accuracy is less important than directional understanding. Use "parking lot" for detailed technical discussions.