Different solutions, different scope. The same standard of proof.

Assess architecture, service, region, resilience, administration and exit context.

The solution profile records the deployment and service model, the provider and the exact services in use, regions and residency, criticality and recovery objectives, privileged administrative paths, and what an exit or a verified deletion would actually require. Infrastructure subgroups such as database, server, platform or infrastructure service, and network each carry their own scope links, so a network assessment and a database assessment do not inherit the controls scoped to the other. Provider material enters as implementation and evidence guidance layered on top of an independent baseline, never in place of one.

Boundary Cloud is a context the profile can describe, not the boundary of the product, and no single provider is assumed. Provider guidance is not a regulatory approval and does not replace independent requirements, validation, or customer-side controls.

Apply group, subgroup and conditional risk-tier context.

Application subgroups cover business and technical applications, web applications and platforms, software as a service, mobile applications, operational technology systems, software as a medical device, and third-party technology services. A risk tier is selected only for the subgroups the governed glossary classifies by tier: controls with no tier restriction stay in scope, controls matching the selected tier stay, and controls restricted to another tier are excluded. The glossary does not classify software as a medical device by tier, so that subgroup is not given one. Digital assets such as a static website, a social media account or a bot are first-class subgroups with their own links rather than an afterthought.

Boundary This is a scoping rule with a recorded reason behind every inclusion and exclusion, not a generic checklist a user picks items from.

Assess AI control implementation and the solution context around it.

When a solution is AI-enabled, the profile extends to the AI use pattern, the supply-chain role, the service layer, the lifecycle stages in scope, the intended purpose, the people affected, human oversight and autonomy, data rights, and how model and prompt changes are governed. Two separate records follow: an AI security control checklist, and an EU AI Act obligation register with its own status, evidence, rationale and Legal approval state. Relevance is suggested by transparent rules over the facts you recorded, and cases that do not match cleanly stay open as reviewable decisions instead of being silently excluded.

Boundary AI control maturity is not legal compliance. A control crosswalk never marks an EU AI Act obligation compliant or Legal-approved, and every role, classification, deadline, exemption and obligation requires qualified legal review.

Record data context, control applicability, evidence and review needs.

Data is a first-class solution type rather than an attribute of something else, so a dataset can be scoped and assessed in its own right. The profile records classification, residency, regions, retention and deletion expectations, and the integrations and privileged paths that reach the data. Where personal data is in scope, privacy and residency signals appear as explicit review prompts, and the relevant privacy sources are registered as conditional overlays carrying their own version, status and verification date.

Boundary No privacy-law determination is produced automatically. A derived privacy or residency signal is a prompt for a qualified reviewer, never a conclusion about lawfulness.

Connect governed controls, sources, mappings and unresolved gaps.

Every control record carries its source, its editorial readiness and its framework references, and the analytical views report those separately so a summary never quietly merges them. Imported legacy references stay visibly distinct from approved current-version mappings. A mapping disposition counts as approved coverage only once it has been reviewed and approved; the default unreviewed state records that no approved mapping exists yet, which is a position in a workflow and not a finding that the control fails.

Boundary Nothing here is a certification, an audit opinion, or a coverage claim. Legacy or unapproved mappings are never presented as current framework coverage.

Capture regulated-use context and the evidence a qualified reviewer will ask for.

The profile records regulated use, electronic-record expectations and the criticality that should drive proportionate assurance, and those facts raise review prompts rather than automatic conclusions. Regulated-use sources sit in the catalog as a conditional overlay with explicit versions, effective status and verification dates, so a draft under consultation is never treated as an effective requirement. Legacy placeholder rows that merely assert a requirement is not applicable have to become explicit, evidence-backed applicability decisions rather than remaining implicit exclusions.

Boundary The product supports validation and assurance planning. It is not a validation, an approval, or a substitute for qualified regulatory and quality review of the specific intended use.

Add governed organization-specific context where the model supports it.

An organization owns its source overrides, its approved internal framework releases, its roles and policies, and the named analysis views its teams reuse across recurring scenarios. Custom roles are scoped to that organization and carry explicit permissions rather than informal convention. Baseline change stays governed: a newer internal release never rewrites an active assessment on its own, and a material change requires a reviewed plan before anything moves.

Boundary This is governed extension inside a defined model, not unrestricted framework authoring. Wider authoring capability is not promised until it is confirmed.