Security, filed under
the exact paragraph of
Article 32 it answers.

Selected security events use stable non-direct principal references for correlation instead of placing direct identifiers in the corresponding event field.

Selected validation diagnostics retain bounded structural information while excluding rejected customer values and exception text.

Shared failure handling returns generic unexpected-failure responses and bounded diagnostics; scoped verification checks representative failure paths for disclosure of protected test values in ordinary responses and operational records.

Covered customer-facing service definitions use managed HTTPS endpoints for inbound application traffic.

Covered server-side paths use authenticated encrypted endpoints for managed platform services; those paths provide no application-defined plaintext alternative.

Current REST API definitions require an enhanced TLS 1.2 or later policy restricted to forward-secret cipher suites; a dated public perimeter check confirmed rejection of TLS 1.0 and TLS 1.1 across the identified production endpoint set.

Current browser-upload flows use authenticated application endpoints rather than direct browser storage writes; upload sessions are account-scoped and time-limited.

Secure-transport enforcement applies at one identified primary customer-data boundary.

Covered download routes authorise account and resource access before issuing action-specific, short-lived storage capabilities.

Reviewed backend transport integrations retain certificate and hostname validation; no application-defined bypass is present in those paths.

Identified structured-data resource definitions require managed server-side encryption for customer and application records.

Default server-side encryption is enforced at the resource boundary for identified primary customer-data and upload stores.

The identified protected recovery copy applies server-side encryption at its resource boundary.

Managed encryption is enabled across the identified structured-data, customer-file and recovery stores.

Encryption for the identified structured records and customer files is applied independently of the application handler performing a read or write.

Identified storage, delivery-artefact and credential-protection functions delegate cryptographic operations to managed services.

Selected reusable integration credentials use a managed key with provider-managed rotation and infrastructure lifecycle safeguards.

Selected credential-decryption paths require the original authenticated customer and connector context.

The same contextual binding applies across selected accounting-connector encryption and decryption paths.

Covered cryptographic permissions are restricted to authorised server-side workloads and the managed keys required for their function.

Delivery artefacts use a configured managed key through the managed delivery service.

Encryption for identified databases and customer-object stores is enforced at the resource boundary independently of business handlers.

Retention and replacement safeguards reduce the risk that routine infrastructure change destroys access to the selected protected credentials.

Covered workloads receive only the cryptographic operations required by their function and no key-administration authority.

Covered contextual credential operations require managed-key configuration before processing protected values.

Customer-facing connector inventory responses are assembled from allowlisted state without cryptographic authority or protected credential material.

Covered application code receives cryptographic operation results without receiving managed-key material.

Cryptographic assurance remains limited to the identified managed-service boundaries, selected credential paths and recorded configuration scope; material change requires fresh evidence.

Covered server-side workloads resolve designated third-party credentials from managed secret storage at runtime.

The shared production retrieval path requires the designated managed value before covered processing can proceed.

Credential-read permissions are restricted by workload to the designated credential families required for covered functions.

The shared resolver confines resolved values to in-process reuse, outside its logging and customer-record persistence boundaries.

Selected authentication-status responses expose only workflow-required state while excluding credentials and authentication-factor secrets.

Selected authentication-denial checks require credential terminology and protected synthetic values to remain absent from client-visible bodies.

Managed integration execution uses a controlled minimal environment that excludes unrelated inherited configuration.

External-provider integration execution is segregated from ordinary managed verification and requires explicit activation.

Assurance receipts retain control outcomes, deployment bindings and lifecycle state without making runtime secret values part of the receipt schema.

Selected development disclosure checks inspect deployed workload configuration and a bounded operational-record window for recognised credential material without retaining record bodies.

Assurance for this control is limited to designated credential paths and the recorded scope of selected development disclosure checks.

A managed identity service performs password and token verification separately from application data stores and business services.

Customer membership begins through administrator-controlled invitation rather than unrestricted public self-registration.

Account recovery is configured for administrator control and is not exposed as a self-service identity workflow.

Authentication responses suppress user-existence details to reduce account enumeration.

Access, identity, refresh and authentication-challenge credentials have bounded validity, and refresh credentials support revocation.

A valid managed identity grants no business access unless current customer membership and server-side authorisation also succeed.

Managed perimeter verification inventories covered bearer-protected routes and requires missing and invalid credentials to be denied without protected-state change.

Managed password policy enforces length and character-composition requirements for new or changed credentials.

Administrator-issued onboarding credentials expire within a bounded period and require replacement before normal member access.

Repeated invitation requests resolve to the existing ordinary-member identity, while incomplete provisioning removes newly created identity state before retry.

The managed customer-identity store is protected against deletion and retained through ordinary infrastructure replacement.

Administrator-led ordinary-member removal withdraws both managed identity and application membership, and older bearer credentials cannot restore access.

These controls apply to the identified customer-identity configuration, ordinary-member lifecycle and covered bearer-protected application paths.

Release configuration separates ordinary release control from final production approval.

The normal release-control authority cannot submit the final production-approval decision.

Final approval is bound to the candidate awaiting production promotion.

Approval configuration limits normal final-approval authority and makes its use subject to enhanced authentication.

The pending candidate and its required release record are validated before final approval.

The normal release path includes a separate human approval step before production promotion.

Personal MFA management is available only within an authenticated member session.

Factor changes bind to the current signed-in member rather than a client-selected identity.

Activation requires a current code from the newly associated authenticator.

Removal requires a current code from the active authenticator.

Factor-status responses disclose state without returning the setup secret.

TOTP-enabled sign-in requires a current authenticator code, and invalid factor changes leave factor state unchanged.

Factor-management requests without valid member authentication are denied.

After perimeter authentication, Legiscope reloads the authoritative user record and constructs server-side identity context before protected business actions are evaluated.

Identity construction fails closed when current membership or entitlement is absent or inconsistent, so stale identity claims do not independently preserve application access.

The shared permission engine evaluates the requested resource and action and denies access when no matching authority exists.

Covered member-administration actions require current administrator authority and server-side membership state.

Covered long-running work revalidates authority before protected processing continues.

Scoped development execution covers permitted and denied authorisation decisions for selected protected actions.

Covered negative mutation cases require the relevant protected state to remain unchanged after denial.

The effective customer account is derived from the authenticated user's authoritative record rather than selected from request data.

Canonical record operations incorporate the server-selected customer account in their addressing strategy.

Canonical customer-file references are constructed from server-selected tenant context and validated resource identifiers.

Covered file access resolves the authenticated customer and authorises the parent resource before delegated transfer access is created.

Covered storage boundaries accept only canonical object references belonging to the authenticated customer scope.

Cross-customer development exercises use two closed synthetic customer accounts and exclude production customer data.

Dated adversarial development cases supplied another customer's valid record identifiers and required denial or a non-disclosing result across the covered actions.

Dated customer-file isolation cases required the requesting customer to receive neither another customer's content nor usable delegated access.

Covered denied mutation cases required the other customer's protected state to remain unchanged.

Both synthetic customer scopes are inventoried after covered exercises so isolation assertions include residual-object and cleanup state.

Execution lanes with incomplete customer-scope cleanup are quarantined from authoritative evidence until their state is released.

Covered request handling rejects malformed or ambiguous input before business processing.

Covered input models reject undeclared scope and attributes before protected state is changed.

Covered updates preserve server-owned customer and record identity.

Covered creation paths prevent silent replacement of existing customer records.

Covered concurrent changes reject stale state rather than silently overwriting a newer decision.

Covered file transfers remain bound to the authenticated customer and authorised transfer context.

Covered file acceptance reconciles the authorised transfer and records an integrity reference.

Covered document workflows apply type, size and structural admission checks before accepted content enters later processing.

Covered multipart finalisation reconciles the complete authorised part set against recorded part versions, sizes and content identities before computing an integrity reference over the assembled bytes.

Covered file admission rejects selected active, embedded, external or executable content structures and bounds decoded streams, archive expansion, object traversal and image dimensions before acceptance.

Dated scoped development executions rejected malformed, duplicate, stale and invalid-file cases without the protected mutation or downstream work challenged by those cases.

Participating security events use a defined shape and stable pseudonymous customer and principal references, supporting correlation while reducing direct identifiers in the covered event families.

Covered validation events retain the control, outcome and bounded structural context while omitting rejected values and exception text.

Security telemetry configuration removes bearer credentials from the covered edge-log path before ordinary retention.

Infrastructure configuration gives the covered edge-security stream an explicit bounded retention period rather than an undeclared default.

Managed integration receipts bind each outcome to its source, deployed scope, expected coverage and cleanup state.

The managed evidence workflow rejects a complete-pass result when expected coverage is absent.

Release receipts preserve the candidate, verification verdict and approval relationship without embedding reusable approval credentials.

Selected access-denial events retain a bounded request reference, the attempted action and a pseudonymous principal reference without recording the protected resource identifier.

The covered edge-log reconciliation verifies credential masking, log redaction and bounded retention after configuration change and refuses a successful result when the expected safeguards are absent.

Dated scoped development execution required selected hidden, foreign, restricted and unknown-resource requests to produce attributable denial markers while protected record terms remained absent from ordinary logs and protected state remained unchanged.

Customer APIs and application functions use managed cloud services, avoiding dependence on a single self-managed application server.

The managed structured-data layer can adapt request capacity without a fixed application-managed server allocation.

Identified production structured-data stores keep continuous recovery points.

Deletion safeguards and infrastructure retention policies protect identified structured-data stores against routine accidental destruction during ordinary infrastructure changes.

Storage configuration preserves recoverable prior versions for identified customer-file stores after ordinary overwrite or deletion.

Selected production customer-file storage has a private, encrypted and versioned copy in a separate geographic region.

Covered production database recovery points are additionally copied to a separately administered environment in a second EU region, so loss of the primary environment does not remove the copy.

Restoration from that separately administered copy is exercised on an automated cycle, so recoverability is evidenced by completed restores rather than inferred from configuration.

Production entry points in the assessed inventory are covered by centrally managed application-layer protection.

The assessed edge protection uses multiple provider-maintained rule groups without publishing defensive rule topology.

Configuration reconciliation compares intended protected surfaces with deployed association state so covered drift can be identified.

A selected blocked-request signal is monitored and routed to designated operators.

Security findings retain their supporting material, scope and remediation state until disposition.

After covered configuration changes, reconciliation re-reads the rule fingerprint, association set, credential masking, log redaction and retention and fails if they diverge.

The covered notification topic has confirmed email and SMS subscriptions for the selected blocked-request signal.

All objects in the covered primary production customer-file store fall within an enabled replication rule to a separate geographic region.

The geographically separate destination is private, encrypted and versioned for the covered storage class.

Deletion-resistant retention prevents ordinary privileged actions from shortening the applicable retention period for protected destination versions.

The covered replication path uses managed replication-time control and emits metrics for threshold breaches and failed replication operations.

Managed assurance records bind controlled verification definitions and produced artifacts through integrity references checked during qualification.

A result cannot qualify when expected coverage, deployment stability, cleanup or evidence-integrity conditions are incomplete.

Each assurance record binds execution identity, assessed deployment and completion time to its outcome.

Produced verification reports are bound to their recorded outcome totals and integrity references before qualification.

Related assurance records become authoritative only when their required group is complete and identity-consistent.

Validated attempt records preserve prior records, and current status is derived from identity-consistent records.

The historical internal development execution completed its assurance catalogue with validated status bindings and without a recorded evidence-integrity, coverage or lifecycle failure.

Assurance-record integrity is limited to the managed evidence workflow and recorded development scope; material change requires fresh candidate-specific evidence.

Active structured-data resource definitions require continuous recovery points for the covered records.

Identified production structured-data stores keep continuous recovery points.

Storage configuration preserves recoverable prior versions for identified primary customer-file and upload stores after ordinary overwrite or deletion.

The deployed backup plan selects covered production structured-data stores by resource pattern rather than by individual tagging, so a newly created store is included without a manual step.

The deployed plan keeps two retention tiers for covered structured data — daily recovery points retained for sixty days and monthly recovery points retained for a year — within bounded execution windows.

A scheduled evaluator compares the declared inventory of covered stores against completed recovery points every six hours, and treats a missing evaluation result as unhealthy rather than as healthy.

Selected customer-file storage retains a private, encrypted and versioned geographically separate copy.

Active structured-data resource definitions keep managed recovery points within encrypted storage for the covered resources.

Deletion protection is enabled across identified production structured-data stores.

Application configuration applies retention safeguards to identified structured-data stores during ordinary infrastructure deletion or replacement.

Storage configuration makes identified customer-file stores private, encrypted and capable of retaining recoverable prior versions.

Resource-level public-access safeguards protect identified customer-file stores against accidental public exposure.

Deletion-resistant retention prevents ordinary privileged actions from shortening the applicable retention period for protected versions in the geographically separate copy.

Covered database recovery copies are held in an environment administered separately from the production environment, so an administrator of the production environment cannot delete them.

Covered production databases keep continuous recovery points restorable to any second within a trailing 35-day window, setting a five-minute recovery-point objective for structured customer records.

Identified customer-file storage retains every prior version, so the recovery-point objective for overwrite or deletion of a stored file is zero.

The geographically separate copy of covered customer data is produced from twice-daily backup windows and carries a twenty-four-hour recovery-point objective.

Restoring an identified database or customer-file store within the primary region carries a four-hour recovery-time objective.

Rebuilding the covered service within the primary region carries a twenty-four-hour recovery-time objective; rebuilding in the second EU region after loss of the primary carries a forty-eight-hour objective.

The published objectives are Legiscope-declared targets: automated restore cycles confirm that covered stores can be restored, but no dated end-to-end exercise measuring recovery time is published, and customer-specific contractual objectives are agreed separately where applicable.

Covered production database recovery points are copied into a vault held in a separate environment in a second EU region, outside the administrative reach of the production environment.

The destination enforces a fixed retention period that cannot be shortened, and recovery points in it cannot be deleted before expiry by an operator of either environment.

The destination policy permits copy-in only, from a single authorised production identity; no other principal and no other operation is accepted.

Routine verification of the copy uses a standing credential limited to reading vault metadata and recovery-point listings for that one destination, with no ability to write, copy or delete.

Recovery material is encrypted with a customer-managed key under automatic rotation, and the destination environment holds only the decryption authority the copy operation requires.

An evaluator running in the destination environment checks every expected store for a fresh completed copy on a six-hour cycle, alarms on absence rather than only on reported failure, and raises the same alarm if its own result stops arriving.

Restore cycles run from the deployed schedule rather than on request, so the exercise does not depend on someone remembering to perform it, and a completed cycle is the evidence that the copy restores.

Each cycle restores from the most recent recovery point within a trailing thirty-day window, so degradation of a stored copy is detected rather than assumed absent.

Restores are performed inside the separate recovery environment; a test cannot write to, replace or disturb production data.

Restored copies are deleted automatically when the cycle completes, so restored customer records exist for the shortest period the exercise requires.

The identity used for restore testing holds no record-level read or write permission: it can create, describe, restore and delete the test copies and nothing else, so proving a copy restores does not involve reading customer records.

The tested scope starts with a deliberately small set of covered stores, including those most recently brought into the plan, and widens once the behaviour and cost of a cycle are established.

A written process defines declaration, an immediate containment sequence, preservation of evidence before repair, and closure, with a timestamped incident log kept from the first minute.

Scenario playbooks cover AI-provider account or key compromise, customer administrator takeover, privileged cloud or delivery credential compromise, cross-tenant disclosure, data destruction and ransomware, build supply-chain compromise, and the notifiable personal-data-breach path.

A breach-assessment aid separates the notify, do-not-notify and document-only outcomes, and treats the processor obligation to inform the affected customer as running from the moment of awareness rather than from a later internal milestone.

A permanent incident register retains each declared incident and its facts as the record required of a processor, independently of the product’s own customer-facing incident workspace.

Each playbook states how that incident would actually be detected given the monitoring in place, rather than assuming an alert that does not exist.

OWASP ASVS 5 provides the requirement vocabulary for structured internal application-security self-assessment.

Each internal assessment record carries a typed outcome, confidence, control layer, technical evidence, findings, recommendations, references, audit date and assessed source revision.

The managed integration harness exercises deployed development services through real application entry points across scoped authentication, authorisation, tenant isolation, input-handling and data-lifecycle controls.

Runtime security checks use closed synthetic development tenants for cross-customer cases and prohibit production targeting.

The assurance design binds expected and executed coverage, source state, deployed scope and cleanup outcome to the result it produces.

The historical internal development campaign completed its then-active service catalogue without a recorded test, coverage or cleanup failure.

Shared controls use a canonical assessment baseline, while covered services retain separate results for inherited controls, service-specific code and infrastructure.

Source assessments and deployed runtime results retain distinct provenance, keeping each conclusion bound to the layer and state it actually examined.

Verification evidence is limited to its recorded source, deployment and coverage scope; material change requires fresh candidate-specific evidence.

Controlled source revisions are bound to the candidate selected for the normal release workflow.

Generated release artifacts move between controlled stages through encrypted storage.

Infrastructure, service and delivery changes are declared in controlled infrastructure templates.

The normal release controller binds exact backend and frontend revisions to the corresponding delivery execution before verification begins.

Development, pre-production and production progression are represented as distinct stages.

Managed integration verification runs against the candidate after controlled development deployment and before later-stage release.

The backend verification wall exercises authentication, authorisation, tenant isolation, API behaviour and lifecycle controls across the active service scope.

Protected identity and access-control checks cannot produce a green release verdict while unresolved.

The evidence design reconciles deployment identity, expected coverage, source consistency, cleanup and residual-state checks before authoritative success.

Normal release orchestration is separated from final human production approval.

Final production approval uses short-lived, MFA-gated authority distinct from normal release control.

Later-stage progression remains controlled until candidate checkpoints and the human release decision complete.

The release receipt relates the selected revisions, delivery execution, verification verdict and approval decision.

Material security findings retain their evidence, affected scope, customer consequence and remediation state until settled.

Documented assessment criteria distinguish observed or proven-reachable issues from plausible or theoretical concerns before priority is assigned.

Customer consequence is assessed separately from evidence certainty, across affected breadth, access or exposure, duration and retention, detectability, available workaround, operational recovery and reversibility.

A concern with no established path to a harmful result is withdrawn rather than retained at a low priority.

Whether a behaviour is wrong is assessed separately from whether it has been demonstrated against a deployed environment, and source inspection alone never raises the demonstrated state.

A control that is not established is recorded as a named verification gap carrying the exact observation that would settle it, and never receives a defect priority.

Priority follows the demonstrated customer consequence, and regulatory, privacy or security labelling does not raise it by itself.

Every assessed requirement carries an owning layer, and a presentation-layer behaviour never discharges a server-side security obligation.

A finding that carries a regulatory obligation records the party to whom that obligation is owed, and its acceptance requires a named decider and an explicit customer-disclosure decision.

An accepted finding is held in a single register with an observable trigger condition rather than an open-ended deferral.

A finding that rests on an unobserved or disputed risk passes a separate review gate before it is retained, and that gate can change the assigned priority.

Each assessment records separately whether any misuse, disclosure or customer harm was observed, so a control weakness is not presented as an incident.

An assessment result whose evidence is incomplete carries an explicit unestablished outcome naming the further evidence required, rather than a pass or a defect.

Finding assessment and triage evidence is limited to its recorded assessment scope and stated evidence state; no measured remediation service level follows from it.

Covered application and shared-component dependencies are declared in version-controlled manifests assigned to the consuming service or shared package.

Covered service templates declare their managed runtime explicitly, making runtime changes controlled source changes.

Dependency installation or package assembly failure fails the managed build and blocks later progression in the same delivery execution.

Selected direct dependencies are fixed to exact versions in the manifest owned by the consuming service or shared package.

Selected dependency requirements use both minimum and upper version boundaries to constrain automatic resolver changes.

The managed dependency installer uses the same runtime generation declared by covered service and shared-component definitions.

The managed build installs each declared dependency set within its assigned service or shared-component package boundary.

A dated production configuration inventory records runtime selections across the assessed function estate.

Covered infrastructure, service and shared-component packages require a non-empty release output before the managed build can continue.

Assurance remains limited to the declared dependency requirements, configured runtimes, assessed delivery path and dated deployed-function inventory.

The current standard requires re-verification of the affected control before a confirmed security repair is closed; code completion alone is not closure.

The current standard requires verified closure to be recorded in the active security record and applicable release decision.

Security-action records assign an intended owner and define the evidence and completion condition needed for closure.

The managed re-test design relates evidence to the repaired source and assessed deployment state so an earlier result does not qualify a later candidate.

Coverage, deployment stability and cleanup failures prevent an otherwise successful managed re-test from qualifying as closure evidence.

Penetration testing of the application is performed by testers external to the Legiscope development team.

A monthly AI-assisted adversarial campaign examines the backend with full access to its source, split across independent specialists for authentication and tenant isolation, input boundaries and AI or tool boundaries, infrastructure, secrets, dependencies and supply chain, and abuse cases, business logic and destructive workflows.

An independent verifier challenges every candidate finding, and a deterministic judge rather than a model decides the campaign outcome against schema, evidence-level and threshold rules, so a model-only claim cannot become a finding or raise an alert.

Evidence levels are explicit and ordered — hypothesis, complete source-to-outcome trace, isolated local proof, and proof in a managed development environment with a cleanup receipt — and missing coverage produces an incomplete result rather than a pass.

Review agents work from an immutable source snapshot with no network access, no cloud credentials, no customer data and no production data; the authorised target list is a committed manifest that a person must extend, and discovery of an asset never authorises testing it.

Durable campaign records carry the policy and scope in force, the reviewed source revision, the coverage attempted and the outcome, and exclude raw output, credentials, request material and customer data.

Confirmed findings from either activity are recorded, assigned and re-verified under the same closure standard applied to other security findings.

Test reports and detailed findings are made available through controlled due diligence rather than published on this page.

Covered bearer-protected interfaces require denial for both missing and invalid credentials within the assessed inventory.

A qualifying result incorporates assertion, deployment, coverage, cleanup and evidence-integrity outcomes rather than application assertions alone.

Expected and executed verification coverage are reconciled before a result qualifies.

A qualifying result requires complete and stable assessed deployment state.

The assurance design binds the controlled verification definitions used to produce each result.

Cleanup and residual-state outcomes are qualifying components of the result.

The historical internal development execution completed its authentication-perimeter control without a recorded coverage or lifecycle failure.

Verification evidence is limited to its recorded candidate, deployment and coverage scope; material change requires fresh candidate-specific evidence.

Application source is scanned automatically for known insecure patterns before a change can enter the deployment path.

Infrastructure definitions are scanned for excessive or escalating permissions, embedded credentials, publicly exposed storage and missing recovery settings.

The repository is scanned for committed credentials, keys and tokens.

Known vulnerabilities are checked against the dependency versions actually packaged into each deployed service, not only the versions declared in the manifests.

Scan results are compared against a recorded baseline: a newly introduced finding blocks the change, and the baseline is reduced only by fixing findings.

The scanned route inventory is derived from the service definitions themselves, so the tested surface cannot drift from the routes actually deployed.

Every target is verified to belong to the development environment before a scan starts; a target that cannot be proved to be development is refused.

The default scan is limited to read operations; anything that writes requires an explicit decision and a disposable development tenant.

Testing behind the authentication boundary uses a development credential; an unauthenticated scan evidences only that the boundary rejects it.

An internal audit programme defines what is audited, on what cycle, and how a nonconformity is recorded, corrected and closed.

Management review is held on a scheduled cadence and appended to a running log, so a review that changed nothing is still visible as a review that happened.

An operating calendar states what is checked monthly, quarterly and annually, together with the defined events that force an out-of-cycle review.

Technical findings from source assessment, scanning, adversarial review and contract conformance are consolidated into a single vulnerability register and triaged monthly, rather than left in separate reports.

Privileged access is reviewed quarterly and suppliers annually, each recorded with its date in a dedicated register, alongside a maintained asset inventory and a dated register of policy exceptions.

An evidence index records where the proof for each control lives and names the places where evidence does not yet exist, so an evidence gap is visible rather than implied.

Evaluation independence is limited: the same person builds, operates and evaluates the system. This limitation is recorded in the audit programme rather than presented as independent assurance.

Covered application operations require managed authentication and a separate current server-side authorisation decision.

Covered customer records and files derive customer scope from authoritative server-side identity rather than a client-supplied account identifier.

Covered write paths admit allowlisted fields, protect server-owned identifiers and condition sensitive state transitions to reduce unauthorised or ambiguous alteration.

Production configuration for identified structured-data stores includes recovery and deletion safeguards against accidental loss.

Covered customer-file stores remain private, encrypted and versioned, providing storage-layer recovery from ordinary overwrite or deletion.

Managed edge-inspection telemetry masks authentication credentials at both sampling and logging boundaries.

Security review classifies evidential certainty separately from the severity of customer consequence.

Risk treatment considers affected breadth, access or exposure, duration, detectability, available workaround, operational recovery and reversibility.

Managed application-layer filtering protects registered production application entry points and the managed identity perimeter.

Identified customer files maintain a separately protected, deletion-resistant recovery copy.

The managed identity store applies retention and deletion safeguards against accidental loss of the covered authentication boundary.

Managed development verification exercises selected application controls and qualifies results only when expected coverage, deployment integrity and cleanup are complete.

The historical internal development campaign completed its then-active non-AI service catalogue without a recorded test, coverage, lifecycle or cleanup failure.

Risk-treatment evidence remains limited to the identified application paths, production resources, internal review method and historical internal development assurance.

Covered authentication-perimeter checks require denial for missing and invalid credentials, prevent disclosure of protected identifiers and verify that the probes leave customer state unchanged.

Covered operation-authorisation checks require denial before protected domain state, related records, asynchronous work, usage, billing, provider activity or file state can change.

Covered cross-customer checks require foreign and unknown identifiers to be indistinguishable, prevent disclosure and preserve the owning customer’s record and related storage state.

Covered request-boundary checks reject malformed or non-object payloads, undeclared fields and client-defined customer scope before access or protected-state change.

Covered document-admission checks reject unsupported or internally inconsistent files before downstream work or charging.

Selected rejection checks compare exact denial outcomes with before-and-after state across each side-effect class relevant to the operation, including delayed effects.

Covered asynchronous-work checks require denied submissions to create no workload, usage or charge and re-evaluate the persisted principal’s current authority before execution.

Covered upload-session checks bind the uploader, customer, purpose and destination and require complete, stable content and an integrity check before promotion to canonical storage.

A historical managed development campaign completed its then-active non-AI service catalogue without a recorded assertion, coverage or lifecycle failure.

Each result remains limited to the assessed component, source, deployment, environment, coverage and verification case; material change requires fresh evidence.

The managed integration workflow is restricted to development.

Managed integration cases use dedicated synthetic customer tenants prepared for the run.

A managed result qualifies only when cleanup, sterile inventory and lease release are satisfactory.

A lane with unresolved lifecycle state is quarantined from reuse, and its result does not qualify.

Qualifying results bind the tested deployment, verification source and recorded development environment to the result.

Each tenant-mutating lane holds fenced, exclusive authority over its dedicated synthetic tenant allocation for the run.

Managed synthetic tenants start from a protected baseline and admit only run-scoped fixtures.

State-changing cases require a prepared managed lease and credentials that resolve to the dedicated synthetic tenant.

External-provider cases are explicitly selected and remain separate from routine managed integration runs.

These controls are limited to the managed integration workflow and the development scope recorded for each result.

The risk method is named and followed rather than improvised: EBIOS Risk Manager for the study, ISO/IEC 27005:2022 for the risk process, ISO/IEC 27001:2022 Annex A as the control reference, and STRIDE as the elicitation aid in the threat-model workshop.

An asset inventory identifies the business values the platform protects and the supporting technical assets that carry them, with a classification of the personal data held and the controller or processor role that applies to each category.

A data-flow map documents how customer data moves through the platform and identifies every trust boundary it crosses, including the boundary where document content reaches AI providers, together with the storage location of each covered data class.

A threat model applies STRIDE to each identified trust boundary and builds operational attack scenarios as complete paths from a threat actor to a concrete harm, rather than as isolated weaknesses.

A risk register records each retained risk with its severity, likelihood, existing controls, residual level, treatment decision, accountable owner and target date; severity is assessed on breadth, duration, reversibility, detectability and regulatory exposure, and likelihood on how difficult the path actually is against the deployed system.

Every rating carries an explicit evidence classification stating whether the path has been observed, proven reachable through a complete technical trace, or assessed as plausible but not demonstrated; risks that are only theoretical are excluded by policy and the exclusions are recorded.

One named person is the accountable risk owner, and risks that are accepted rather than treated carry a formally recorded and dated acceptance decision.

A treatment plan sequences the resulting actions in waves with target dates, so the analysis produces scheduled work rather than a document.

The scoping, risk-origin and ecosystem workshops are re-run annually against a scheduled date, and the threat model, risk register and treatment plan are reviewed monthly against current findings.

A defined trigger list forces an out-of-cycle review: a new third party processing customer data, a new trust boundary, a material change to the identity or authorisation model, a change to what customer data reaches an AI model, a security incident, the arrival of a second privileged operator, or a new customer requirement.

Every review appends a dated entry to the review log, including a review that changes nothing, so an unreviewed register and a reviewed-and-unchanged register cannot look identical.

OWASP ASVS 5 provides the requirement vocabulary for structured internal application-security self-assessment.

Each internal result distinguishes its requirement outcome, confidence, control layer, technical support, finding, remediation, reference, assessment date and assessed source revision.

Selected platform-security checks compare deployed development inventory and customer-browser authority with stated control expectations.

Dated configuration assessments compare selected deployed security settings with intended configuration instead of treating source alone as deployment proof.

Qualifying managed results bind expected and executed coverage, stable deployed identity and cleanup outcome to the recorded result.

Shared-library controls use one canonical assessment baseline, while service-level results separately assess whether each service correctly inherits or applies that control.

The managed integration harness exercises deployed development services through real application entry points across reviewed functional, authentication, authorisation, tenant-isolation, input-handling and data-lifecycle cases.

Where a managed lane acquires test state, qualification requires its expected coverage, deployment stability, cleanup, sterility, leak checks and release state to satisfy the recorded run contract.

A historical complete non-AI development campaign completed its then-active service catalogue without a recorded assertion, coverage, cleanup or run-integrity failure.

Internal assurance evidence is limited to its recorded source, deployment, coverage and execution scope; material change requires fresh candidate-specific evidence.

Managed identity services perform password and token verification while Legiscope retains responsibility for configured factors, customer membership and application authorisation.

Managed request and compute services operate covered workloads while Legiscope retains responsibility for interface classification, authorisation, input validation and business behaviour.

Managed structured-data services provide the storage platform while Legiscope retains responsibility for customer scope, query design, conditional updates, recovery configuration and record lifecycle.

Managed object-storage services provide the storage platform while Legiscope retains responsibility for private access, customer scope, versioning and authorised lifecycle operations.

Application and infrastructure configuration assign covered cryptographic and credential operations to managed services while Legiscope retains responsibility for policies, workload authority, secret scope and integration behaviour.

Managed build and delivery services operate the normal delivery platform while Legiscope retains responsibility for candidate selection, verification, approval authority and deployed application correctness.

Managed web-application filtering protects registered production entry points while Legiscope retains responsibility for coverage, inspection policy, sensitive-field protection and response.

Managed inspection telemetry records covered edge events while Legiscope retains responsibility for sensitive-field handling, retention and review within that scope.

Managed recovery features support covered data services while Legiscope retains responsibility for selecting protected resources, configuring recovery controls, validating restores and governing restored-data access.

Inherited provider responsibility is limited to the identified managed-service inventory and does not replace Legiscope application, configuration or operational controls or certify the Legiscope application.

An approved information security policy, a defined scope and system description, named roles and authorities, and eight topic-specific policies covering access control, secure development and change, logging, monitoring and vulnerability management, backup, continuity and recovery, data classification and cryptography, supplier and third-party management, AI and model use, and acceptable use and endpoint security.

A Statement of Applicability covers all 93 ISO/IEC 27001:2022 Annex A controls, each recording applicability, justification and status — implemented, partial, applicable but not yet implemented, inherited from the cloud provider, or excluded with a stated reason — so a partial control is visible as partial.

The same programme is mapped to the AICPA Trust Services Criteria for Security, Availability and Confidentiality, with a readiness assessment that names the qualifications an examination would raise today rather than only the criteria that are met.

Nine measurable security objectives carry recorded baselines, so the programme is assessed against measures rather than against intentions.

A consolidated statement of customer-facing security commitments may contain only controls the Statement of Applicability records as implemented; anything partial appears there as a stated limitation rather than as a promise, and the two documents are reconciled on a fixed cadence.

Legiscope holds no ISO/IEC 27001 certification, no SOC 2 report and no other security certification, and claims none; provider certifications remain attributed to the provider.

Covered customer operations require current server-side authorisation after authenticated identity has been resolved.

A covered action is denied unless the current principal holds an explicit grant for its resource and action.

Authenticated browser cloud credentials carry no direct application or identity-administration authority.

Covered application execution roles accept assumption only from the managed compute service.

Customer-member access levels expand server-side into fixed read, write and delete capability sets rather than accepting a browser-authored permission tree.

Customer-member access changes require administrator authority, and request data cannot confer administrator status.

Customer scope is derived from authenticated server-side identity, and request data cannot select another customer account.

Covered records are addressed within the authenticated customer partition, with ownership rechecked before an object is returned.

Selected in-account records remain subject to controller scope in addition to the action permission.

Permission and controller-scope decisions use a single current access-state snapshot and fail closed when that state cannot be resolved.

Assistant-mediated actions use a non-administrator subject capped by the originating user’s authority, and write access requires an additional assistant grant.

Each publicly startable asynchronous operation declares either its required permission set or a payload-aware authorisation boundary.

Queued customer work reconstructs the persisted initiating principal and repeats current permission and scope checks before protected processing.

Least-privilege assurance is limited to the identified application paths, role inventory and recorded verification scope; material change requires fresh evidence.

Repository rules restrict ordinary production investigation to approved read-only access and prohibit diagnostic mutation.

Production investigation is limited to the minimum fields and records needed for the assigned question.

Production records remain transient and are not persisted or transferred outside production without express authority for the specific context.

Credentials, tokens, secrets and unrelated personal data are excluded from investigative commands, tool output and reports.

Investigation reports retain only the minimum non-sensitive derived evidence needed to support their conclusions.

Managed integration execution accepts only defined non-production test targets.

Live integration mutation fails closed until the testing environment, cloud account, service endpoints and test identities match the designated development boundary.

Selected deployed-security inventory runs without tenant credentials and returns only redacted control findings.

Selected sensitive-log checks return only redacted finding metadata and do not persist inspected message contents.

These handling controls are limited to covered repository operations and managed test workflows.

All Legiscope staff are required to complete the company’s internal training programme.

The required programme includes the full Legiscope DPO training curriculum.

The DPO curriculum incorporates IT-security training alongside data-protection instruction.

CEO Dr Thiébaut Devergranne conducts all internal staff training.

Dr Devergranne has 25 years’ professional experience in data privacy and served as a French national expert advising the French Prime Minister during the GDPR negotiations.

The public position covers the mandatory curriculum and its internal delivery while individual completion records and assessment results remain confidential.

Training content is documented and version-controlled: the curriculum is drawn from the security policies themselves across nine modules — programme foundations, data classification and handling, acceptable use and endpoint security, access and authentication, event reporting and incident response, breach recognition and the notification clocks, and, for technical roles, tenant-isolation invariants and model-egress rules — so what was taught can be inspected rather than described.

Induction is completed before or on access and a refresher runs annually and on any material policy change.

Completion is evidenced by a dated attestation signed by the individual, naming the modules and the document version of each; self-declared completion with no artefact is not treated as evidence.

The attestation requirement applies to the person delivering the training as much as to anyone else, and the training record shows outstanding cycles as outstanding rather than omitting them.

The assessed cloud-identity inventory covers root status, persistent user credentials and console-access conditions.

The identity inventory records credential age and use together with direct user policy attachment for technical review.

Root access is protected by multi-factor authentication and carries no active root access key.

Covered protected-data and identity-administration operations remain outside browser-held authority.

The technical review model accounts for grants originating from both assigned identities and resource policies.

Covered workload trust policies restrict role assumption to the intended managed compute service.

Dated development verification binds the authority result to an unchanged deployment fingerprint and recorded control scope.

Technical access-review assurance is limited to the recorded cloud-identity inventory and scoped development controls; broader personnel and service-access certification requires separate current evidence.

Protected application requests resolve the authoritative user and customer relationship on each request, so removed or invalid membership fails closed despite older identity claims.

Current server-side user and group access state governs each covered permission decision, so access reductions apply on the next request.

Covered queued work re-authorises its persisted principal against current membership, permissions and customer scope before protected processing begins.

Administrator-led member removal withdraws both the provider identity and application membership while preserving business and compliance records.

Customer-directory invitation, access editing and ordinary-member removal require administrator authority.

The ordinary-member removal path refuses administrator identities and confines the target to the requesting customer.

Active work attributed to a removed member must reach a stopped state before reference cleanup can complete.

Deleted-member references are detached from the declared customer-data inventory without deleting the records that carry retained business facts.

Repeated member-removal requests resume the same durable cleanup state instead of creating parallel lifecycle work.

Cleanup completion requires the declared reference inventory to contain no remaining deleted-member identifiers.

Reference cleanup uses conflict-aware writes so concurrent customer-record changes are not silently overwritten.

Access-revocation assurance remains limited to covered authorisation decisions, ordinary customer-member removal and the declared reference inventory.

Personnel controls apply to every natural person with access to Legiscope information or systems regardless of employment status, in four recorded categories: operational personnel, professional advisers, contractors, and sub-processor staff governed through their employer’s contract.

Screening is proportionate to the access granted and is completed before any credential is issued, with re-screening on a material change of role or access.

Where an individual holds regulated professional status, that status is recorded as the primary screening basis because it is externally verifiable at any time and carries admission assessment, continuing conduct obligations and a disciplinary body; a criminal-record extract supplements it rather than replacing it.

No person in any covered category receives access without a signed confidentiality undertaking in force; an adviser’s professional secrecy obligation is treated as additional to that undertaking, never as a substitute for it.

Professional advisers with company financial or contractual access hold no production, customer-data, source-code or cloud-administration access, and that separation is confirmed at each quarterly review rather than assumed.

For a joiner, screening, the confidentiality undertaking and security induction are all completed before the first credential is issued, and access is granted at the role’s minimum rather than copied from another person.

For a mover, access is re-based on the new role rather than added to it, because accumulated authority from a previous role is the ordinary failure mode of access control.

For a leaver, access is revoked on the last day of access rather than the last day of work, assets are returned, and surviving confidentiality obligations are confirmed in writing; an ended adviser or contractor engagement is treated as a leaver event.

A personnel register records each person’s category, access scope, screening basis, confidentiality undertaking, induction and training status, together with a dated log of every joiner, mover and leaver event.

People and their access — not only credentials — are reviewed on a quarterly cycle covering human identities, long-lived machine credentials, third-party provider accounts, the devices used for privileged access and source-repository access; a review that changes nothing is still recorded as a review.

The device standard requires full-disk encryption, automatic security updates on a supported operating-system version, active endpoint protection, a short screen-lock timeout, an enabled firewall, a working account used by no one else, and device backups that exclude or encrypt customer-data caches.

A device failing any mandatory requirement of that standard may not be used for privileged work until the requirement is met, and device posture is confirmed at each quarterly review.

Handling rules bind the device as well as the person: customer data is held only transiently for the task in hand, never copied into development environments, fixtures, prompts, tickets, repositories or messages, never placed on removable media, and credentials are never stored in plaintext files or shell history.

Central endpoint management with remotely verifiable posture is not yet in place; it is recorded as a dated policy exception with an owner rather than presented as met.