Encryption posture, key management, privileged access, environment isolation, vulnerability and pen-test evidence where available.
Operational assurance and deployment fit
Operational Reliability, Security, Data Lifecycle & Integration Controls
This page gives institutional, procurement, IT-security, DFI, donor, and sovereign reviewers a compact public map of the operational reliability, security controls, data lifecycle, sovereignty precision, integration surfaces, service structure, and safeguard/risk-control evidence that should be tested during protected diligence. Public statements on this page define the review posture and minimum control domains; binding uptime, recovery, support, security, residency, identity federation, API availability, and integration obligations remain deployment-specific and must be confirmed in the applicable contract, SLA, security pack, data-processing agreement, and protected walkthrough.
Current Assurance Status
Public governance narrative is not a certification, SLA or deployment guarantee. The table below clarifies what the public site does and does not assert.
| Domain | Public status | Minimum evidence to request |
|---|---|---|
| Security certifications | No public SOC 2 / ISO attestation is asserted. | Certification, readiness evidence, compensating controls or third-party audit evidence. |
| Penetration testing | Pen-test evidence is not published as public proof. | Latest independent pen-test summary and remediation status where applicable. |
| SLA / uptime | No universal public SLA applies to all deployments. | Deployment-specific SLA, support hours, response bands, RPO/RTO and DR commitments. |
| Integration assurance | Public pages describe integration control domains only. | API documentation, data-flow map, SAML/OIDC posture, service-account scopes and integration audit logs. |
Procurement-safe evidence request
Procurement, vendor-risk and IT/security reviewers can use the minimum evidence request as the working list for protected diligence: governance configuration, security and operational assurance, data lifecycle and residency, integration controls, programme-specific configuration and contractual commitments.
For IT/security reviewers
Use this page as the technical control orientation. The detailed tables below are depth; the minimum artefacts to request are:
Uptime band, support model, incident response, monitoring boundary, RPO/RTO and restore/failover evidence.
Residency statement, retention/deletion logic, raw versus derived data handling, withdrawal and export controls.
API boundaries, identity federation, secure ingestion lanes, MRV/spatial handling and integration audit logs.
ESG/IFC/ESS mapping where applicable, incident/grievance route and risk-register interface.
Public limitations to close in protected diligence
The public site intentionally distinguishes between institutional posture, deployment-specific commitments, and independently evidenced controls. The following areas should be closed through protected review, contractual schedules, security packs, or independent evidence before institutional reliance.
| Potential weakness | Why it matters | How to close it in diligence |
|---|---|---|
| Minimal public disclosure on security certifications or independent audits | IT security, procurement, and regulated clients cannot rely on governance narrative alone as proof of control maturity. | Request SOC 2, ISO 27001, penetration-test, third-party security review, readiness assessment, or security-questionnaire evidence where available. If certification or independent audit is not complete, document readiness path, compensating controls, owner, and target evidence. |
| No universal published SLA or reliability target | Programme owners and fiduciary reviewers need contractual reliability commitments before relying on the platform for operational or committee deadlines. | Request the deployment-specific SLA/service schedule, uptime target band, maintenance windows, monitoring responsibilities, incident route, support hours, response bands, RPO/RTO, and failover/restore evidence. |
| Limited public detail on interoperability with existing institutional architectures | Procurement, IT architecture, MRV, data, and identity teams need to understand how the Hub fits into existing systems without weakening sovereignty, audit, or access boundaries. | Request API documentation, data-flow diagrams, ingress/egress formats, connector inventory, SAML/OIDC requirements, service-account scopes, export templates, machine-readable export options, and integration audit logs. |
1. Security posture
Terra Vita Hub is designed for ministries, DFIs, multilaterals, supervisory authorities, and regulated institutional actors that require security controls beyond governance narrative. Deployment-specific security evidence should be reviewed under the applicable security pack, DPA, SLA, protected walkthrough, and contractual schedule.
Core controls
| Control | Institutional posture | Evidence to request |
|---|---|---|
| Encryption in transit | TLS 1.2+ for application traffic, integration endpoints, and protected access surfaces. | Protocol posture, certificate management, endpoint inventory, and exception register. |
| Encryption at rest | AES-256 or equivalent provider-backed storage encryption for governed records, backups, logs, and export artefacts where configured. | Storage encryption statement, backup encryption statement, and deployment storage boundary. |
| Key management | Segregated environment-scoped keys under strict access boundaries, with rotation, custody, and BYOK/HYOK posture documented where required. | Key-management model, rotation posture, separation-of-duties evidence, and BYOK/HYOK availability statement. |
| Privileged access | Individually-bound, identity-verified, least-privilege profiles with full action logging for administrative and elevated operations. | Privileged access matrix, admin action logs, support access route, and deprovisioning evidence. |
| Environment isolation | Production, staging, and development run as isolated environments with separated credentials, data boundaries, and deployment controls. | Environment map, credential boundary, release pathway, and non-production data-handling rule. |
| Network controls | Restricted ingress/egress, internal segmentation, monitored endpoints, and deployment-specific network boundary where applicable. | Network boundary description, allowed endpoints, monitoring coverage, and exception approval route. |
Hardening
Institutional production deployments should be supported by independent annual penetration testing evidence or a documented readiness path with compensating controls until the first testing cycle is complete.
Continuous scanning, vulnerability disclosure intake, severity triage, time-bound remediation, dependency patching, and emergency patch handling should be documented for protected review.
Code-review mandates, multi-party approvals for material changes, version-controlled deployments, validation summaries, and rollback controls support institutional change assurance.
SOC 2, ISO 27001, third-party audit, or independent readiness evidence should be provided where available. Public governance narrative should not be treated as an attestation.
2. Operational reliability and service guarantees
Operational dependability must be testable, not inferred. Availability, incident response, monitoring, disaster recovery, change management, and support commitments should be deployment-specific and recorded in the applicable SLA or service schedule.
Availability
| Control area | Institutional posture | What to test |
|---|---|---|
| Target uptime | Designed for high availability with a target uptime band of 99.5%+ where contractually adopted for an institutional deployment. | SLA/service schedule, uptime target, dependency boundary, historical availability where available, and remedy language. |
| Scheduled maintenance | Maintenance should be performed in low-usage windows with prior notice and release notes for institutional users where applicable. | Maintenance policy, notification template, release calendar, and emergency maintenance route. |
| System resilience | Auto-scaling and health-checked workloads should be used where supported by the deployment architecture. | Architecture note, monitoring boundary, health-check scope, scaling posture, and dependency register. |
| Monitoring and alerting boundaries | Monitoring responsibilities should define what Terra Vita monitors, what infrastructure providers monitor, what the institution sees, and what remains outside scope. | Monitoring coverage, alert categories, notification recipients, alert-to-action workflow, and evidence of alert handling. |
Continuity
| Area | Institutional posture | Evidence to request |
|---|---|---|
| Recovery Point Objective | RPO ≤ 1 hour where adopted for the contracted deployment and supported by the hosting architecture. | BCDR statement, backup cadence, point-in-time restore posture, and restore evidence. |
| Recovery Time Objective | RTO ≤ 4 hours where adopted for the contracted deployment and supported by the operational playbook. | Failover playbook, restore-test evidence, continuity dependency register, and escalation path. |
| Backups | Backups should be encrypted, region-bound, and retained across multiple snapshots according to the deployment’s sovereignty and retention posture. | Backup configuration, region/residency statement, retention snapshots, and restore test record. |
| Failover | Regional failover pathways should be controlled by operational playbooks and constrained by data-residency rules. | Failover region map, approval route, sovereignty exception treatment, and recovery test evidence. |
Incident response and support
A defined incident-response framework should cover detection, containment, remediation, institutional communication, post-incident review, and time-bound closure under strict severity windows.
Support should define availability hours, severity bands, response windows, named support or account contacts for regulated clients, escalation pathways, and closure evidence for governance-blocking issues.
Versioning, deployment controls, multi-party approvals, regression testing, rollback triggers, and validation summaries should distinguish documentation changes from protected logic, auth, schema, and operational-code changes.
Institutions should receive clear routes for scheduled maintenance, incident notification, release posture, emergency changes, and escalation of regulated-client support issues.
3. Data lifecycle and sovereignty
Data sovereignty is not only a hosting-region statement. Institutional reviewers should test retention, destruction, withdrawal, lineage, raw-versus-derived handling, export controls, temporary evidence, rejected evidence, overridden evidence, and tenant isolation across the full object lifecycle.
Data retention
| Object type | Retention posture | Reviewer evidence |
|---|---|---|
| Evidence objects | Retained according to programme mandate, institutional agreement, donor requirement, or jurisdictional rule. | Retention schedule by object class, programme authority approval, and legal-hold posture. |
| Reviewer actions and logs | Retained as long as required for audit, supervisory compliance, non-repudiation, and decision reconstruction. | Audit-retention rule, reviewer log sample, and deletion/archival boundary. |
| Derived intelligence | Retained only while required for governance posture, reporting, committee review, or institutional assurance. | Derived-output taxonomy, expiry rule, source-record linkage, and suppression pathway. |
Object destruction, withdrawal, and revocation
Where institutional policy or regulatory requirement mandates destruction, primary data should be securely removed through a multi-phase deletion process while audit preservation or deletion follows the governing authority’s legal parameters.
Derived outputs should be decoupled from originating objects and removed or suppressed where required, without silently breaking authorised audit reconstruction.
When an institution withdraws a submission or requests output suppression, linked exports halt circulation, derived assessments stop propagating, and evidence lineage remains intact for audit unless a regulatory mandate requires removal.
Incomplete uploads, rejected records, overridden conditions, and temporary review objects must have explicit state rules so they do not drift into committee packs or disappear without audit context.
Data sovereignty controls
| Control | Deployment configuration | Minimum proof to request |
|---|---|---|
| Hosting region | Jurisdiction-specific hosting constraints are selected and documented per deployment. | Hosting-region statement, residency addendum, and infrastructure evidence. |
| Access rules | Access is governed by role, institution, programme, jurisdiction, and purpose. | Role matrix, RLS/access tests, support-access boundary, and deprovisioning evidence. |
| Export controls | Exports follow purpose, recipient, redaction, watermark, expiry, residency, and authority rules. | Export control policy, recipient register, snapshot sample, and reproducibility test. |
| Retention ceilings | Retention periods and deletion/archival rules are configured to deployment mandate and legal requirements. | Retention schedule, deletion workflow, legal-hold procedure, and closure evidence. |
| Isolation options | Sovereign, dedicated, or air-gapped environments may be scoped where ministries or regulated authorities require strict isolation. | Deployment model decision record, tenancy design, storage boundary, integration boundary, and support-access constraints. |
| Multi-tenant isolation | Shared institutional environments require strict tenant, storage, auth, audit, and export separation. | Tenancy model, cross-tenant inference test, RLS policy evidence, and storage bucket boundary. |
4. Integration and interoperability
Institutional reviewers need to know how Terra Vita Hub fits into existing infrastructure without weakening evidence lineage, audit reconstruction, identity assurance, export governance, or sovereignty boundaries. Integration is purpose-bound, logged, and configured to the deployment.
Evidence ingress
Evidence files can be submitted through controlled upload routes with programme context, source metadata, state, and reviewer visibility attached.
Structured evidence, programme records, MRV references, and registry extracts can be mapped into governed objects where the deployment permits it.
Data feeds must be purpose-bound, authorised, and tied to programme records so imported information does not float outside context.
Remote-sensing, GIS, satellite, and spatial inputs should preserve source, timestamp, boundary, method, and confidence metadata.
Registry connectors can be scoped where programme-specific agreements exist, with data-copy versus reference treatment clearly documented.
Enterprise identity and API access
| Surface | Institutional posture | What to test |
|---|---|---|
| Identity federation | SAML 2.0 and OIDC support can align reviewer access with institutional identity, MFA, hardware-token enforcement, and role-scoped privilege mapping where configured. | Federation requirements, role mapping, MFA enforcement, login/audit trace, deprovisioning test, and external reviewer expiry evidence. |
| Controlled APIs | Institutions can integrate through controlled APIs for evidence creation, authorised programme-output retrieval, committee-pack extraction, and verification of reviewer actions or posture states. | API documentation, authentication model, object scope, rate/error handling, service-account owner, audit logs, and deactivation route. |
| RLS and audit boundary | All API access operates under strict row-level security boundaries with full audit logging and service-account accountability. | RLS access tests, service-account scope, failed-access handling, audit event sample, and integration error/retry logs. |
Reporting and export
The Hub supports controlled exports of evidence summaries, governance posture, committee-ready packets, and structured outputs for risk teams and supervisory reviewers. Exports preserve institutional privacy, recipient purpose, watermarking, expiry, redaction, versioning, and governance constraints.
| Export class | Typical format | Governance condition |
|---|---|---|
| Committee-ready packets | PDF and document-style packs where configured. | Snapshot ID, evidence lineage, reviewer actions, conditions, unresolved risks, and export log. |
| Structured outputs | CSV, XLSX, JSON, or machine-readable extracts where configured. | Data dictionary, role scope, purpose, recipient class, and re-use boundary. |
| Risk and supervisory exports | Governance posture summaries, evidence registers, exception logs, and assurance packs. | Redaction review, role-governed disclosure, watermark/expiry, and audit reconstruction reference. |
5. Risk and safeguard controls
Environmental, social, and governance safeguard evidence can be mapped to institutional frameworks such as IFC Performance Standards, World Bank Environmental and Social Standards, donor safeguard policies, or programme-specific requirements where applicable. Terra Vita Hub preserves safeguard evidence, conditions, reviewer findings, escalation posture, grievance/incident route, and closeout status; it does not replace the safeguard authority or verifier.
The governance architecture can connect to credit, operational, environmental, safeguards, fiduciary, procurement, or portfolio-risk processes through evidence registers, risk-register interfaces, exception logs, committee packs, and controlled exports. The Hub does not make risk acceptance, lending, statutory, or investment decisions.
6. Service structure and deployment options
Deployment options should be selected according to institutional risk, sovereignty, programme complexity, integration needs, and review authority. The deployment model changes operational boundaries; it does not change the authority boundary.
| Deployment model | Use case | Control expectation |
|---|---|---|
| Shared institutional environment | Multi-tenant operating environment where institutional isolation, RLS, storage boundaries, and export controls are sufficient for the review purpose. | Strict tenant isolation, role-governed access, audit separation, and no cross-tenant inference. |
| Dedicated environment | Institution-specific or programme-specific deployment where region-locking, integration scope, or assurance posture requires a dedicated environment. | Region-locked hosting, dedicated configuration, separate support boundary, and environment-specific assurance evidence. |
| Sovereign or air-gapped deployment | Ministries, regulated authorities, or sensitive sovereign programmes requiring strict isolation, disconnected operation, or controlled synchronisation. | Sovereignty decision record, offline/controlled-network posture, synchronisation rules, export approvals, and audit capture. |
Terra Vita Hub provides governance surfaces, operational controls, evidence workflows, review routing, and export posture. It does not perform statutory approvals, lending decisions, legal determinations, or official MRV verification.
Institutional deployments should define time-bound response tiers, named contact channels for regulated environments, and escalation pathways for governance-blocking issues.
7. Independent oversight and assurance
Independent oversight evidence should be made available under NDA or protected diligence where required. Public pages should identify the evidence class and assurance route without implying that every certification, audit, or review has already been completed for every deployment.
| Assurance area | Institutional expectation | Evidence route |
|---|---|---|
| External review | Independent security assessments, annual penetration tests, and external governance/risk posture evaluations should be available or scheduled according to deployment risk. | Security assessment summary, penetration-test summary, remediation register, readiness assessment, or third-party review evidence under NDA. |
| MRV compatibility review | Programme-specific MRV compatibility reviews should be available where a deployment depends on approved methodologies, verifier workflows, or sector-specific evidence standards. | MRV compatibility note, methodology attachment map, verifier role treatment, and MRV-to-decision linkage evidence. |
| Segregation of duties | The platform should support multi-reviewer integrity so no single user can intake evidence, approve it, and set final funding posture without cross-review or explicit compensating controls. | Role matrix, SoD test, override protocol, two-person integrity evidence where applicable, and audit replay of high-risk actions. |
| Override assurance | Overrides require identity-bound justification, authority basis, scope, expiry, and appearance in audit replay. | Override log, rationale record, approval authority, expiry/condition, and committee-pack visibility. |
Minimum evidence to request in protected diligence
| Review area | Minimum evidence | Pass criteria |
|---|---|---|
| Public limitations | Security certification/attestation status, SLA status, reliability target status, interoperability documentation status, and gaps or roadmap items. | Reviewer can distinguish public narrative, protected evidence, contractual commitment, third-party attestation, and future-readiness item. |
| Security posture | TLS/encryption statement, AES-256 or provider-equivalent encryption evidence, key-management model, privileged access matrix, environment isolation design, network boundary, pen-test/remediation evidence where available, vulnerability-management process, and code-integrity controls. | Security claims are evidenced, current, role-owned, and not treated as proven merely because governance language exists publicly. |
| Operational reliability | SLA/service schedule, 99.5%+ target band where adopted, maintenance-window policy, monitoring/alerting coverage, incident-response structure, support hours, severity matrix, named support contacts, and escalation route. | Commitments are documented, operationally owned, contractually clear where required, and aligned with institutional criticality. |
| Disaster recovery | RPO/RTO bands, encrypted backup cadence, region-bound backup posture, restore evidence, regional failover posture, continuity dependency register, and restore-test or readiness record. | Recovery expectations are explicit, testable, and consistent with data residency and sovereignty constraints. |
| Change management | Version register, release notes, code-review and multi-party approval route, deployment approval route, regression checklist, rollback plan, and separation of documentation changes from auth/schema/business-logic changes. | Material changes are reviewed, traceable, reversible where applicable, and do not silently alter institutional controls. |
| Data lifecycle and sovereignty | Retention schedule, destruction/withdrawal workflow, raw/derived data taxonomy, evidence-state model, export control policy, residency addendum, dedicated/sovereign/air-gapped posture where required, and tenancy/RLS/storage isolation tests. | Data handling is explicit across source, derived, temporary, rejected, overridden, exported, logged, and deleted records. |
| Integration governance | Integration inventory, API documentation, data-flow map, service-account scope, connector purpose, SAML/OIDC requirements, ingress validation, export formats, structured-output options, error/retry logs, and audit treatment. | External systems cannot bypass programme controls, evidence lineage, access boundaries, or export rules. |
| Safeguards and risk | Safeguard framework map, evidence-object taxonomy, condition/escalation rules, grievance/incident route, committee-pack export sample, and risk-register linkage. | Safeguard and risk evidence remains linked to reviewer actions, conditions, escalation, closeout, and export posture without replacing institutional authority. |
| Independent oversight | Independent security assessment, annual penetration-test evidence or readiness path, governance/risk posture evaluation, programme-specific MRV compatibility review, SoD test, and override audit replay. | External assurance, reviewer segregation, override controls, and MRV compatibility are documented before institutional reliance. |