Controls

Production database backups, point-in-time recovery, and restore-test evidence are maintained for the critical Activity Analysis database.

High availability and private-networking treatment is documented as an open readiness decision before production certification scope.

Administrative and service activity is logged through the managed cloud and application control plane for review and incident response.

Operational monitoring and alerting are configured for the production portal, supporting services, and scheduled automation paths.

Production infrastructure uses managed network controls, restricted service exposure, and deployment-specific access boundaries.

The core security policy suite is drafted and versioned; formal communication and operating evidence remain part of the readiness track.

Security ownership, escalation routes, and operational responsibilities are documented for the active Teho team.

Access is limited to authorised team members and deployment-specific service roles with evidence retained for review.

User and administrative access rights are tracked and reviewed against the current team and deployment scope.

Independent review is not yet complete and remains a required readiness item before an external certification claim.

Incident planning, severity handling, communications, and client notification expectations are documented.

Security events are triaged through documented escalation and assessment procedures.

Response runbooks cover containment, investigation, communication, and remediation responsibilities.

Post-incident review and remediation tracking are part of the documented operating model.

A tabletop exercise is planned to preserve operating evidence for the incident response process.

Where optional AI providers are used, the vendor, data category, region, and transfer basis are named before signature.

AI-enabled classification is configured per deployment and limited to the agreed engagement purpose.

Clients can request non-LLM or reduced-data paths where the engagement risk profile requires it.

AI use, model/provider choice, and deployment controls are captured in the security review pack when relevant.

Privileged access is restricted to named administrators and deployment-scoped service roles.

Application access is scoped by role, deployment, and approved operational need.

Administrative and service access require authenticated sessions or deployment-scoped credentials.

TLS is used for service interfaces and managed encryption is used for storage services in production deployments.

Security checks, dependency review, and targeted verification are included in the release process for touched surfaces.

Controller and processor responsibilities, optional providers, data categories, and deployment-specific privacy terms are documented.

The business question, teams, workflows, signal categories, exclusions, reviewer audience, and reporting level are named before a Baseline begins.

Baseline outputs are constrained to team or workflow-level findings, with below-threshold small-group activity suppressed from named reporting.

Screenshot, semantic, or LLM-enabled evidence paths are deployment-specific and require explicit approval before use.

Retention and deletion procedures are agreed before deployment, with deletion evidence available on request.

Sensitive fields can be reduced, excluded, or masked depending on the deployment and review scope.

Exports, service access, and optional AI paths are constrained to the agreed deployment scope.

Supplier terms and subprocessor disclosures are maintained, with final evidence narrowed to the actual deployment scope.