Sovereign Cloud Security Framework (SCSF) Platform

Complete User Guide

Document Version: 3.2.0 Target Audience: Security Consultants, Cloud Architects, Compliance Auditors, SOC Leads, and Platform Administrators

§Welcome to the SCSF Assessment Platform

The SCSF Platform provides a structured, repeatable methodology to assess sovereign cloud posture, identify regulatory exposure (such as US CLOUD Act, EU NIS2, DORA, BSI C5:2026, and India DPDP), formulation of remediation roadmaps, and ongoing compliance monitoring.

This guide provides step-by-step operational instructions for all platform roles and modules.

§Table of Contents

1. User Personas & Role-Based Navigation
2. Getting Started: Authentication & Client Onboarding
3. Module 1: Readiness Assessment (Manual Questionnaire)
4. Module 2: Evidence-Backed Assessment (Hybrid Cloud)
5. Module 3: Cloud Configuration Scan (Automated Cloud Discovery)
6. Module 4: Brownfield Compliance Review & POA&M
7. Module 5: SOC Sovereignty Readiness & Compliance Review
8. Module 6: Quantum Readiness & Compliance Assessment
9. Module 7: Interpreting Results, Radar Charts & Decision Trails
10. Module 8: Evidence Management & Confidence Scoring
11. Module 9: Remediation Roadmap & POA&M Tracking
12. Module 10: Portfolio Assessment & Sovereign Migration Planning
13. Module 11: Continuous Monitoring, Drift Detection & CI/CD Gate
14. Module 12: Generating Executive Reports, CSV Exports & Share Links
15. Module 13: Platform Administration & License Management
16. Frequently Asked Questions (FAQ) & Troubleshooting

§1. User Personas & Role-Based Navigation

The platform automatically tailors the navigation experience based on your assigned role:

§2. Getting Started: Authentication & Client Onboarding

Step 2.1: Logging In

1. Navigate to the platform URL in your modern browser (e.g., https://scsf.your-domain.com or http://localhost:3000).
2. Enter your Username and Password.

• If your organization has enabled Single Sign-On (SSO), click Sign in with SSO (Okta / Entra ID).
• If Multi-Factor Authentication (MFA) is enabled, enter your 6-digit TOTP authenticator code when prompted.

1. Upon successful authentication, you will be redirected to the Journey Home dashboard.

Step 2.2: Creating or Selecting a Client Organization

Assessments are strictly isolated by client organization. Before creating an assessment, you must establish or select the active client:

1. Click Clients in the top navigation bar (/clients).
2. To create a new client:

• Click the blue + New Client button.
• Enter the Client Name (e.g., Acme Financial Services Europe).
• Select the Primary Region (e.g., European Union, Germany, France, United States, India).
• Select the Industry Sector (e.g., Financial Services, Healthcare, Public Sector, Critical Infrastructure).
• Choose the Target Sovereign Framework (e.g., EUCS High, DORA, SecNumCloud v3.2, BSI C5:2026).
• Click Create Client.

1. To switch between existing clients, click on the client's name card or use the Switch Client selector in the top bar.

Step 2.3: Starting an Assessment — Assessment Context & Workload Plans

Every Readiness, Evidence-backed or Configuration Scan assessment starts at Assess -> Start Assessment (/assessment):

1. Choose the module (Readiness Assessment, Evidence-backed Assessment or Cloud Configuration Scan) and click Continue.
2. Agree the scope brief with the customer (Assessment Context). Five short questions, filled in with the customer in about ten minutes; every one can be answered "not sure yet":
3. What decision will this assessment help you make? — e.g. Can this workload move to, or stay in, the cloud?, Which sovereign cloud option fits us?, Are we compliant today? (suggests the Brownfield Compliance Review), Prove sovereignty to a regulator, auditor or customer, Reduce dependency on a provider. Add the customer's own words, who makes the decision, and a name for the engagement.
4. Why now? — the trigger (regulation, audit finding, customer or tender requirement, foreign-government access concern, board mandate, contract renewal) and when the answer is needed.
5. What should we look at? — each workload gets the same questions, because different applications hold different data and run in different places: what kind of data it holds, where it runs today, which environments, how sensitive its most sensitive data is, what a day without it would mean (criticality), and who owns it. Copy answers from the previous workload, then change what differs. If the customer can't name the workloads yet, give a rough number and describe a typical one. Also note anything out of scope. For a workload plan, these answers become each workload's profile in the workbench; for a single workload they pre-fill the assessment (name, data sensitivity, criticality, and the platform for a configuration scan).
6. What has already been decided? — the jurisdiction the data must stay in, and known must-haves (own encryption keys, local or cleared operators, disconnected operation, exit time, approved AI models).
7. Who should we talk to? — the people who can answer each part of the questionnaire.

• Each question shows an Ask it like this prompt for the consultant; tick Screen-share mode to hide them when the customer is watching.
• What we heard summarises the answers; Copy as email produces a confirmation the customer can check. Ask the customer to have ready lists the documents their answers call for (e.g. key-management design when they hold their own keys).

1. One workload: click Start assessment. The module opens with the workload name and jurisdiction filled in, and the brief is stored with the report.
2. Two or more workloads: click Create workload plan. Each workload gets its own evidence, score and report — they are never merged into one assessment. The plan, the report banner and the workbench show the decision, why now, the jurisdiction and the must-haves.

The Assessment Workbench (/assessment/engagement/<id>)

A workload plan opens in the Assessment Workbench:

• Configure profile for each workload: owner, Data classification (Public, Internal, Confidential, Sensitive, Restricted, Secret, Top Secret), Business criticality (Critical, High, Medium, Low), platforms and environments. Classification and criticality use the same values as the assessment modules because they drive the architecture recommendation's hard gates (for example, Secret data always requires Air-Gapped; a Critical workload needs an average score of at least 85 to avoid it).
• Module scans: every workload can run all three modules; the plan's chosen module is marked primary. Adding AWS, Azure, GCP, OCI or OpenShift to the profile enables the Configuration Scan. Opening a module pre-fills the workload name, classification and criticality.
• Save & return to workload workbench (top of each module) keeps the draft against that workload's module run, so it can be resumed from any device.
• Progress: a workload is complete when its primary module has an issued report; the other modules are optional and never hold the plan open. When every workload is complete the plan shows as complete.
• Engagement roll-up: average readiness score across the primary reports, how many workloads received each architecture recommendation, and the lowest-scoring workload with a link to its report. Each module button shows its report's score and recommendation.

Unfinished plans are listed under Assessment workbenches on the Start Assessment page; completed plans are kept there behind Show completed workload plans. Every report from a plan shows the engagement, the workload's position (e.g., workload 1 of 4), the module and the workload profile — on screen, in the PDF and in share links — and History links each assessment back to its plan (Plan: <name>). Deleting a report (admins only) reopens that workload's module so it can be run again.

§3. Module 1: Readiness Assessment (Manual Questionnaire)

The Readiness Assessment is the foundational questionnaire evaluating sovereign posture across the 7 pillars (Data, Operational, Technological, Legal, Identity, Governance, and AI Sovereignty).

End-to-End Steps:

1. Click Assess -> Start Assessment, size the engagement (see Step 2.3), then choose Readiness Assessment — or open it from a workload in the Assessment Workbench (/assessment/manual).
2. Workload Scoping:

• Confirm your active Client.
• Enter a descriptive Workload Name (e.g., Core Banking Settlement Engine).
• Specify Deployment Model (e.g., Public Multi-Tenant, Dedicated Sovereign Region, Hybrid Cloud, On-Premises Enclave).
• Select Data Classification (Public, Internal, Confidential, Sensitive, Restricted, Secret or Top Secret) and, optionally, Workload Criticality (Low, Medium, High or Critical). When the assessment was opened from a workload plan these are pre-filled from the workload profile.
• Choose What are you assessing? — Current environment (how the workload runs today; gaps are migration prerequisites) or Planned target design (the design you intend to move to, tested before the move). Run both for the same workload to get the Current state vs target design comparison on the Posture & POA&M Overview: controls the design closes, leaves open, or introduces. Target-design runs are labelled everywhere (Results, Posture, History) and are never used as the drift baseline for the live environment.
• Choose the Applicable Frameworks (auto-mapped from region and industry). The panel separates them into:
• Sovereign framework — primary: the scheme that defines sovereignty for the jurisdiction (e.g. EUCS, BSI C5, SecNumCloud, FedRAMP High, IRAP, NCA CSCC) — where data may be held, which law applies, who operates the service and who can be compelled to disclose data. Where a region has no sovereign-cloud scheme (e.g. India, Singapore), the panel says so and names the closest framework as the sovereign anchor.
• Supporting frameworks: Regulatory obligations the workload must also meet (NIS2, DORA, GDPR, EU AI Act, MAS TRM, …), Security baselines whose existing certificates and audit evidence can be reused (ISO 27001, CSA CCM, NIST CSF, ISO 22301, …), and Sector standards (PCI DSS, ISO 27799, IEC 62443).
• Click ⓘ on any framework for how it helps and why it is listed; Why more than the sovereign framework? explains the split. The sovereign framework stays primary whatever order you click in.
• Selecting frameworks never changes the pillar scores. Each selected framework flags the questions it mandates, is checked by the architecture recommendation, and gets its own row under Framework Qualification in the report — a qualification tier where the platform has a model, otherwise Control coverage: the open findings in the control families that framework requires (not a certification result).

1. Questionnaire Completion:

• Navigate through the pillar tabs on the left.
• Each question displays:
• The Control Title and regulatory cross-reference.
• Guidance & Verification Tip: Click the ℹ️ View Guidance badge to see exactly what evidence is required.
• Real-world CSP examples (e.g., how this is satisfied in AWS GovCloud, Azure Bleu, or OVHcloud).
• Select the option that best reflects the current architectural state.
• Optional: If you have local Ollama running, click Generate Dynamic Industry Questions to inject 5-10 specialized questions tailored to your sector.

1. Attaching Evidence:

• On relevant questions, click Attach Evidence File to upload corroborating architecture diagrams, policies, or contracts.

1. Submission:

• Once all mandatory questions are answered, click Calculate Sovereignty Score.
• The platform saves the assessment, evaluates mandatory gates, runs AI enrichment, and redirects you to the Results Dashboard.

1. Readiness outputs (open Posture & POA&M for the assessment):

• Blockers — one ranked list of everything that stops the move: hard stops (e.g. EU AI Act prohibited practices), mandatory controls for the region and sector, and qualification blockers of the sovereign framework — each with its fix, roadmap step, owner and target date.
• Assurance — every passing control is self-attested until evidence (reference, description, expiry date) is attached and verified by someone other than the assessor and the person who submitted it. The tab shows which CISO statements the assessment supports — verified, self-attested or not yet supported — e.g. "Only we hold the keys to our data" (Q-DAT-01, Q-LEG-02). Present only verified statements as proven.
• Deliverables — draft Key Custody Playbook, Exit Plan and Landing Zone Blueprint generated from the answers (current state, target model, steps, evidence to collect), downloadable as .docx. They are drafts for the consultant to complete and validate before issue.
• Controls added in this release: break-glass governance (Q-IDN-07), in-jurisdiction patching and engineering (Q-OPS-09), tenant and data isolation (Q-TEC-08), AI model provenance (Q-AIS-13) and AI event logging / EU AI Act Art. 73 serious-incident reporting (Q-AIS-14).
• Controls added for the EU Cloud Sovereignty Framework (question set 2026-10-29): governing law and venue (Q-LEG-06), change-of-control notice (Q-LEG-07) and an Environmental Sustainability section (Q-ENV-01 to Q-ENV-04), asked only for EU and Nordic regions and never scored into the pillars; it rates SEAL objective SOV-8.
• Auto-save: answers save as a draft a few seconds after each change and when you leave the tab (also on SOC Readiness, Brownfield Compliance and SOC Compliance). Reopen the page to Resume or Discard; drafts are listed in Assessment History.

1. Reassessment (re-measure the same workload after remediation):

• Click Reassess on the assessment in History, ↻ Reassess on its Results page, or open a new Readiness questionnaire and use ↻ Reassess a previous assessment to pick a completed run.
• The questionnaire opens with the earlier answers filled in, on the Open gaps view: only what the earlier run left open — controls that were non-compliant or unanswered, controls new since that run, and compliant controls whose evidence has expired. Each is labelled with why it is in focus. Update the answer, or press Confirm — no change if it still stands; the progress bar counts reviewed gaps. Closing a gap prompts you to attach evidence.
• Every other control is compliant — carried forward: it keeps its earlier answer and still counts towards the scores. Switch to All questions to change any of them; changed ones are reported as re-checked, a carried-forward control that now fails as a regression.
• The Reassessment outcome card (Results, Posture & POA&M Overview, Gap Analysis and the PDF) reports gaps closed and still open, new controls answered, how many controls were carried forward without re-check, closed gaps still lacking verified evidence (self-attested until verified on the Assurance tab), and any focus controls left without review. The outcome is signed with the run. The workload name, client and current/target setting are kept from the original so the runs pair up; the original is never changed.
• The new run is tagged ↻ Reassessment R1 of #<original> (then R2, R3 … for later re-runs of the same chain) on Results, History and Gap Analysis. Runs saved before answers were stored have them rebuilt from their findings: failed controls keep the recorded answer, other controls they asked are set to the passing answer, and controls added since are flagged to answer fresh.
• Compare with the original in Gap Analysis → on the Results page opens Clients → Gap Analysis with the original as Pre · baseline and the reassessment as Post · comparison (Gap Analysis opens on that pairing by default). Controls added to the questionnaire after the baseline ran are listed as Not assessed at baseline, not as regressions.

§4. Module 2: Evidence-Backed Assessment (Hybrid Cloud)

The Evidence-Backed Assessment is designed for complex hybrid architectures where workloads span both public cloud hyperscalers and on-premises physical datacenters.

End-to-End Steps:

1. Click Assess -> Evidence-backed Assessment (/assessment/hybrid).
2. Section A: Cloud Workload Scoping:

• Select your primary Cloud Service Provider (AWS, Azure, or GCP).
• Enter cloud account/subscription metadata.

1. Section B: On-Premises / Private Datacenter Audit Scope:

• Specify the physical facility address and cage/rack location.
• Answer the physical sovereignty checklist:
• Perimeter Security & Biometric Access Control.
• Local Entity Ownership (ensuring facility operator is not subject to foreign parent subpoena).
• Hardware Supply Chain Provenance (FIPS 140-3 HSMs, sovereign server vendors).
• Power, cooling, and air-gapped network perimeter validation.

1. Section C: Cross-Environment Corroboration:

• Complete the hybrid data flow questionnaire (e.g., database replication routes, backup storage locations).
• Upload the Datacenter Audit Certificate (SOC 2 Type II or ISO 27001 Annex A.11).

1. Click Submit Hybrid Assessment to receive a unified, cross-environment sovereignty score.

§5. Module 3: Cloud Configuration Scan (Automated Cloud Discovery)

The Cloud Configuration Scan automates finding discovery by querying live CSP APIs.

End-to-End Steps:

1. Click Assess -> Cloud Configuration Scan (/assessment/automated).
2. Select Provider:

• Choose AWS, Azure, or Google Cloud (GCP).

1. Provide Credentials (Read-Only):

• AWS: Enter AWS Access Key ID, Secret Access Key, and target Region (or leave blank to trigger Deterministic Simulation Demo Mode).
• Azure: Enter Tenant ID, Client ID, Client Secret, and Subscription ID.
• GCP: Upload the read-only Service Account JSON key file.

1. Select Target Framework for Mapping:

• Choose whether findings should map to EUCS High, BSI C5:2026, FedRAMP High, or General SCSF Baseline.

1. Initiate Scan:

• Click Run Automated Scan.
• A real-time terminal window displays progress as the scanner queries KMS key managers, storage bucket policies, IAM configurations, and logging endpoints.

1. Review Discovered Findings:

• The scanner outputs a consolidated inventory of discovered resources, flagged sovereignty violations, and assigns automated finding severities.
• Click Save Assessment & Generate Report.

§6. Module 4: Brownfield Compliance Review & POA&M

The Brownfield Compliance Review is tailored for ongoing production workloads undergoing formal regulatory gap audits.

End-to-End Steps:

1. Click Managed -> Brownfield Compliance Review (/assessment/compliance).
2. Select the client and choose the target compliance catalog (e.g., DORA Financial Resilience or ANSSI SecNumCloud).
3. For each control in the framework:

• Mark status: Compliant, Non-Compliant, Partially Compliant, or Not Applicable.
• Enter auditor notes explaining the control design and operating effectiveness.
• Set Audit Confidence (Verified by API, Documented in Policy, or Self-Attested).

1. Auto-Generate POA&M:

• Any control marked Non-Compliant or Partially Compliant automatically generates a Plan of Action & Milestones entry.
• Set the designated Owner, target Remediation Date, and Remediation Cost Estimate.

1. Click Finalize Compliance Review.

§7. Module 5: SOC Sovereignty Readiness & Compliance Review

The platform provides a 2-stage assessment specifically for Security Operations Centres (SOCs) protecting critical national infrastructure.

Phase 1: SOC Readiness Assessment (The Prerequisite Gate)

1. Click Assess -> SOC Readiness Assessment (/assessment/soc-prerequisite).
2. Evaluate the 5 SOC sovereignty dimensions:

• SIEM & Log Locality: Confirm telemetry and long-term hot/warm storage remain within the sovereign boundary.
• SOAR Execution: Ensure automated response actions (e.g., isolating hosts, revoking credentials) execute locally.
• EDR Telemetry Restriction: Verify memory dumps and process trees do not exit the jurisdiction.
• Analyst Personnel: Verify analysts possess required nationality vetting and 24/7 eyes-on-glass residency.
• Threat Intelligence: Ensure threat feeds operate in offline/air-gapped mirror modes.

1. If the score is >= 80%, the SOC qualifies for Phase 2.

Phase 2: SOC Compliance Assessment

1. Once qualified, click Assess -> SOC Compliance Assessment (/assessment/compliance?soc=1).
2. Execute the full NIS2 / DORA SOC compliance checklist, verifying incident response SLAs (e.g., 24-hour initial notification under NIS2 Art. 23).
3. Generate the SOC Executive Briefing Report.

§8. Module 6: Quantum Readiness & Compliance Assessment

Module 6A: Quantum Readiness Assessment

1. Click Assess -> Quantum Readiness Assessment (/assessment/quantum-readiness).
2. Complete the 5-domain evaluation:

• Cryptographic Asset Inventory & Discovery.
• Algorithm Vulnerability (identifying RSA-2048, ECC, and DH).
• Cryptographic Agility (abstraction layers, certificate templates).
• PQC Algorithm Adoption (ML-KEM / ML-DSA hybrid deployments).
• Hardware Security Module (HSM) upgrade roadmap.

1. Inspect the PQC Agility Radar Breakdown and review the Estimated Migration Cost.

Module 6B: Quantum Compliance Assessment

1. Click Assess -> Quantum Compliance Assessment (/assessment/quantum-compliance).
2. Audit workload alignment against NIST FIPS 203/204/205 and US CNSA 2.0 timelines (2025–2033 migration deadlines).
3. Formulate the Quantum Risk Register detailing high-risk data repositories subject to "Harvest Now, Decrypt Later" exposure.

§9. Module 7: Interpreting Results, Radar Charts & Decision Trails

Upon completing any assessment, you land on the Results Dashboard (/results):

+------------------------------------------------------------------------------------+
|  ASSESSMENT RESULTS: Core Banking Settlement Engine                               |
|  Overall Sovereignty Score: 74 / 100 [TIER: SUBSTANTIAL SOVEREIGNTY]               |
+------------------------------------------+-----------------------------------------+
|              7-PILLAR RADAR              |           FAILED CONTROLS (3)           |
|                                          |                                         |
|                 Data (85)                | [!] CRITICAL: HYOK Key Custody Missing  |
|                     ^                    |     Pillar: Data Sovereignty            |
|       Legal (60)   / \   Ops (75)        |     Impact: -20 Mandatory Gate Penalty  |
|             \     /   \     /            |                                         |
|              \   +-----+   /             | [!] HIGH: Extraterritorial Jurisdiction |
|               \ /       \ /              |     Pillar: Legal Sovereignty           |
|     Identity --+---------+-- Tech (70)   |                                         |
|        (80)   / \       / \              | [!] MEDIUM: AI Prompt Telemetry Egress  |
|              /   +-----+   \             |     Pillar: AI Sovereignty              |
|             /     \   /     \            |                                         |
|        AI (65)     \ /    Gov (70)       +-----------------------------------------+
|                     v                    | DECISION TRAIL & AI FINDINGS ENRICHMENT |
|                                          | - Evaluated with Ollama qwen3:8b        |
|                                          | - Corroborated by 2 AWS config findings |
+------------------------------------------+-----------------------------------------+

Key Elements to Inspect:

1. Pillar Score Breakdown: Hover over any axis on the Radar chart to see specific control pass/fail ratios for that domain.
2. Mandatory Gate Warnings: If a red alert banner appears, a critical sovereign prerequisite failed. Even if other pillars scored 100%, mandatory gates cap the final tier until resolved.
3. Decision Trail Panel: Click Decision Trail to review the exact chain of logic used by the scoring engine, including regulatory citations and AI agent reasoning.

§10. Module 8: Evidence Management & Confidence Scoring

1. On the Results page, locate the Evidence Vault panel.
2. Click Upload New Evidence.
3. Select files from your workstation (accepted: PDF, DOCX, XLSX, PNG, JPG, ZIP; max 10MB per file).
4. Select the Evidence Category (e.g., Architectural Diagram, Data Processing Agreement, KMS Key Policy, SOC 2 Audit Report).
5. Link the evidence to one or more specific controls.
6. The platform immediately scans the file, computes a SHA-256 integrity hash, encrypts the document with AES-256-GCM, and updates the Confidence Score of the associated finding from Low (0.5x) to Medium (0.75x) or High (1.0x).

§11. Module 9: Remediation Roadmap & POA&M Tracking

1. From the assessment results, click the Remediation Roadmap tab.
2. The roadmap organizes corrective actions into 3 execution horizons:

• Horizon 1 (Immediate / Days 1–30): High-impact, low-effort configuration adjustments (e.g., enabling S3 bucket region-lock, disabling global IAM user access keys).
• Horizon 2 (Tactical / Days 31–90): Architecture enhancements (e.g., standing up a local Thales/Utimaco HSM for BYOK/HYOK, deploying an air-gapped log collector).
• Horizon 3 (Strategic / Days 91–180+): Contract renegotiations, cloud-exit portability containerization, or migration to a local sovereign cloud operator.

1. Click Export to POA&M to push these items into the platform's central Posture & POA&M Tracker (/post-assessment), where engineering teams can mark milestones complete.

§12. Module 10: Portfolio Assessment & Sovereign Migration Planning

For organizations managing dozens or hundreds of applications:

1. Click Portfolio in the navigation bar (/migration).
2. Workload Registration:

• Click + Register Workload or use Bulk CSV Import.
• Specify application name, business criticality, current host (AWS, Azure, On-Prem), and data sensitivity.

1. Portfolio Rationalization:

• The platform classifies workloads into 4 Sovereignty Tiers.
• View the Cross-Border Transfer Heatmap showing jurisdictions where data and support access traverse international boundaries.

1. Sovereign CSP Matching:

• Inspect the Target Cloud Provider Ranking. The platform evaluates European and regional sovereign providers (e.g., OVHcloud, Bleu, Delos Cloud, T-Systems) against each workload's technical requirements.

1. Financial ROI & Business Case:

• Click Financial Modeling to view the projected cost of regulatory non-compliance (NIS2 / GDPR fine exposure) versus migration capital expenditure.

§13. Module 11: Continuous Monitoring, Drift Detection & CI/CD Gate

13.1 Ongoing Monitoring

1. Navigate to Managed -> Monitor Progress (/monitor).
2. Configure a periodic scan frequency (e.g., Weekly or Monthly).
3. If an unauthorized infrastructure change occurs (e.g., a developer opens an S3 bucket to public egress or changes KMS key rotation), the Compliance Drift Guardian agent creates an alert and automatically logs a new POA&M issue.

13.2 CI/CD Quality Gate Integration

To prevent sovereignty regression during software deployments:

1. Go to Settings -> API Keys and generate a machine token with ci_gate scope.
2. In your CI/CD pipeline (e.g., GitHub Actions), add a verification step:

curl -X POST https://scsf.your-domain.com/api/gate/check \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"client_id": "CLIENT_UUID", "minimum_score": 80}'

1. If the active score is below 80, the API returns HTTP 412 Precondition Failed, safely halting deployment before non-compliant code enters production.

§14. Module 12: Generating Executive Reports, CSV Exports & Share Links

1. Click Assess -> Exports (/reports).
2. Select the completed assessment.
3. Choose your desired output:

• Executive Briefing PDF: Generates a publication-quality executive summary with radar charts, risk matrices, and C-level takeaways.
• Full CSV Audit Export: Generates an exhaustive spreadsheet containing all 115+ controls, finding descriptions, evidence references, and POA&M milestones (fully protected against formula-injection attacks).
• OSCAL JSON: Machine-readable control assessment output for federal compliance tools.
• Reports that belong to a workload plan carry its context (engagement, workload position, module and workload profile) on screen, on the PDF cover and in share links.
• Create Share Link: Generates an encrypted, time-limited URL (e.g., 7 days or 30 days) allowing external auditors to inspect the results without creating a platform account.

§15. Module 13: Platform Administration & License Management

(Requires platform_admin or admin role)

1. User Administration: Navigate to /admin/users to invite users, reset passwords, enforce MFA, and assign roles (admin, consultant, analyst, client).
2. AI Topology Supervision: Navigate to /admin/ai-topology to view the operational status of all 22 AI agents and 8 security agents. Inspect model latency and execution counts.
3. Agent Health & Watchdog: Navigate to /admin/agent-health to run on-demand self-tests against the local Ollama LLM and cloud API connectors.
4. License Management: Navigate to /admin/license to inspect your current license tier, seat limits, and expiration date. To apply an updated license, paste the cryptographic license JSON and click Install License.
5. Client Modules (platform owner only): Navigate to Clients → Client Modules (/admin/client-modules), or Manage which modules each client can use on the Platform Control Center, to add or remove modules for a client profile after it was created. Click Manage modules, tick or untick modules (or choose Every module in the platform licence to lift the restriction), check the Adds / Removes preview, and click Save modules. Modules the platform licence doesn't cover are shown but can't be selected. The change takes effect the next time the client's users load a page and is recorded in the audit log (client_modules_updated, with what was added and removed). Removing a module keeps the client's existing reports on file but stops its users opening that module. Inside the client workspace, module access is read-only — client users, including the client admin, can't change it.

§16. Frequently Asked Questions (FAQ) & Troubleshooting

Q: Why does the platform recommend NIS2, ISO 27001 or PCI DSS when the region already has a sovereign framework? A: The sovereign framework defines where data lives and which law governs it; it does not cover the region's other legal duties (incident reporting, operational resilience, personal-data processing) or the evidence the customer already holds. Supporting frameworks cover those, never change the pillar scores, and each gets its own row in the report. Open ⓘ on a framework for what it adds.

Q: Why is the Configuration Scan button disabled for a workload in my workload plan? A: The scan needs a scannable platform. Open Configure profile and add AWS, Azure, GCP, OCI or OpenShift under Platforms (any capitalisation), then save.

Q: A workload plan still shows a workload as in progress although one module report exists. Why? A: Only the plan's primary module completes a workload. Reports from the optional modules add evidence but do not count towards completion.

Q: Can I run assessments without internet access in an air-gapped enclave? A: Yes. SCSF is designed local-first. When paired with a local Ollama instance (qwen3:8b) or operating in deterministic fallback mode, zero external network calls are made.

Q: How does SCSF prevent horizontal data exposure between clients? A: Multi-tenant client isolation is enforced at the database layer using Python ContextVar. Queries automatically scope to the active client ID, making cross-client access structurally impossible.

Q: What happens if our local Ollama LLM crashes during an assessment? A: The platform includes an automated fallback mechanism. If the AI endpoint times out or fails, the scoring engine immediately reverts to deterministic heuristic evaluation without interrupting the user.

Q: How do we prove to external auditors that uploaded evidence has not been tampered with? A: Every uploaded file is fingerprinted with a SHA-256 hash upon upload and recorded in the audit log chain. The hash is displayed on the Results page and in exported reports for independent verification.