PoliciesSoftware, data & security

These pages explain our service approach. The applicable signed agreement and service schedule set the work, commercial terms and specific commitments for your engagement. Information on this website does not silently amend an existing signed agreement.

FOR CUSTOMERS & TECHNICAL REVIEWERS

Know the data.
Know the responsibilities.

The proposed rules for access, providers, AI, security, retention and the information a client deployment needs before it goes live.

On this page
01

A service-specific data and security agreement

These service requirements apply when Prospera configures or manages software, company knowledge, automations or other services that handle a client’s information. They supplement the general service policies and the website privacy policy. They identify the matters to be addressed in the service agreement and any data-processing schedule; they are not a platform certification or an executed data-processing agreement.

Before private data is admitted, the order and processing schedule must identify the actual parties, purpose, permitted data, affected people, authorized instructions, providers, locations, safeguards, retention and end-of-service process. If a required restriction cannot be met, that use must wait or be changed.

02

Who is responsible for what

AreaProspera’s proposed responsibilityClient responsibility
Purpose and instructionsProcess the agreed information only to provide the scoped service, maintain its security, meet lawful obligations or follow another documented, lawful instruction. Raise an instruction that appears outside the agreed scope.Identify the lawful business purpose and confirm that the information and intended contact are authorized.
People and permissionsConfigure and operate the access and isolation controls included in the service; limit operator access to the work authorized.Name an accountable owner and approvers, keep user lists accurate and promptly report access changes or suspected compromise.
Content and knowledgeKeep reviewed company sources and draft material distinguishable; route conflicts or missing information for review.Approve offers, prices, policies, scripts, claims and company facts before they become operating guidance.
Providers and actionsUse the agreed providers and activation limits; seek review for material changes to cost, access or data handling.Review required provider terms, fund authorized usage and approve the specific audience, purpose and actions where required.
Rights and incidentsProvide the contractually agreed information and assistance to investigate a request or incident.Coordinate the business response and legal notifications for information under its control, with Prospera meeting its own applicable duties.

An allocation of work does not transfer away a party’s statutory obligations. In particular, outsourcing can leave an organization accountable for personal information under its control. OPC outsourcing guidance.

03

Allowed information and secure admission

Start with the minimum information needed for the job. Use synthetic or properly sanitized examples during design and testing where possible. Do not connect another client’s files or use an existing account’s access simply because it is convenient.

Credentials, recovery material, bank or payment-card details and sensitive or regulated records require an expressly approved use, secure transfer method and safeguards. Ordinary forms, chat, email and Company Brain uploads are not credential-transfer channels. Describe a need for sensitive data during scoping; do not upload the records first and ask later.

Any change in data type, sensitivity, people affected, volume or purpose must be reviewed when it could change the legal or technical risk. Permissions for one dataset or service do not authorize admission to every connected tool.

04

Identity, roles and client separation

The service’s access schedule must identify owners, administrators, staff, customers, operators and any integration identity. It must state who can view, create, change, export, approve and delete each relevant type of information, including any emergency support access.

Use individual accounts, delegated permissions and least-privilege access where supported. Confirm administrator security, multi-factor authentication where available, invitation and revocation rules, secret handling and log access for the actual host. A client user or support worker must not gain another client’s information through a shared screen, query, export, AI context or backup.

These are activation requirements to verify for the selected service. This page does not assert that every existing preview or future client edition has completed all of these controls.

05

Development, testing and production

A working prototype, local preview and production system have different responsibilities. The project plan must identify their environments, permitted data and who can release changes. A successful demo does not authorize private-data migration, a live payment path or customer-facing automation.

Where a staging environment is needed, its isolation, access and cleanup must be agreed. A production copy must not be placed in a developer workspace or sent to an AI tool without the client’s documented authority and appropriate safeguards. Releases should include the agreed tests, review, migration plan, rollback or recovery approach and owner acceptance.

06

Providers, subprocessors and locations

Each engagement needs a provider register describing the service supplied, information permitted, processing locations, account owner, relevant contract, retention controls and any onward-processing dependencies. A vendor logo or region selector is not a complete subprocessor or residency assessment.

Inspected source connectionRole and bounded informationWhat still needs confirmation
Supabase in the existing public-intake routeHosts the Novah function and rate-control contract; the existing public intake uses it for request records. The Novah request can expose ordinary network metadata to that service.The actual project settings, contractual processing terms, relevant regions, logs, retention and onward providers for each use. Vendor subprocessor list.
OpenAI API in the existing Novah routeGenerates a draft from the bounded question purpose and rough answer sent to it. Source requests store: false.The relevant API account’s data controls, retention exceptions, locations and contractual terms. A request setting is not a general zero-retention guarantee. Vendor data controls.
Other hosting, identity, storage, voice, email, social or payment servicesOnly selected when needed for the particular agreed feature.Provider identity and owner, actual data flows, contractual terms, location restrictions, support access and exit method before activation.

This source-based table is a starting inventory, not a finalized list for every Prospera product. The schedule must set notice and review rules for a new or replacement provider that materially changes approved handling, location, access or cost. No Canada-only hosting promise is made.

07

AI use, review and shared learning

The service scope must say which AI task is permitted, which sources may be included, how much information is necessary and what review is required. Provider instructions or a user’s chat message do not override client access, purchasing, privacy or action limits.

AI content can be wrong, incomplete or unsuitable. Drafting, approval and external execution remain separate. The user must review a suggested brief answer before using it; approved operational automations may act only within the limits recorded for that workflow. Material changes to purpose, audience, permissions, spending or approved content require renewed review.

Uploading a document, using the OS or approving an answer does not authorize publication of private material or reuse of client records, recordings or confidential information for other clients or shared model training. Any broader improvement use needs a defined purpose, permitted material and safeguards. Suggested lessons require review; they are not automatically approved company facts.

The applicable AI-provider terms and settings must be verified for the service. We do not infer a provider’s complete retention or training treatment solely from a local code flag.

08

Retention, export, return and deletion

Client-owned data remains client-owned. The agreement must define which records can be exported, in what usable format, who may request them, what dependencies or exclusions apply, and what assistance is included. Service access does not itself convey ownership of Prospera’s source code, reusable framework or every provider account.

At exit, the parties must review pending actions, stop or transfer approved workflows, revoke access, return or export agreed material, and apply the retention and deletion schedule. Data in backups, security or consent records and legal holds can require different handling from active application data.

The schedule must state actual export and deletion periods, exceptions and how completion is evidenced. An export is not proof that every copy is deleted. A backup is not a verified recovery capability until the agreed restoration check succeeds. These periods and procedures must be confirmed for the chosen host; they are set in the applicable schedule.

09

Incident handling and cooperation

The service agreement must name the security contacts and incident route, define the client and Prospera’s coordination duties, and state any contractual notice timing. The response should preserve relevant evidence, contain the problem, assess affected information and people, and coordinate appropriate notices and corrective action.

The client should report suspected compromise and remove or limit unauthorized access where it controls that access. Prospera must meet its own applicable legal duties and agreed assistance obligations; assigning a client notification role does not excuse a failure by Prospera.

Where PIPEDA applies, the legal report-and-notify threshold is a real risk of significant harm, and breach records have separate requirements. OPC breach guidance. Any additional contractual incident-notification deadline is stated in the service agreement.

10

Technical evidence and service continuity

A customer’s technical review should receive evidence for the controls relevant to its proposed deployment, with the date, owner and limits of the evidence. The review must distinguish an implemented measure from a planned control, a vendor certification from a Prospera certification, and a local test from a production test.

  • Access and isolation: roles, authentication, authorization checks and deprovisioning.
  • Data handling: permitted categories, provider flows, locations, encryption and retention.
  • Operations: updates, monitoring, incident contacts, changes and rollback responsibilities.
  • Continuity: backup ownership, restore testing, recovery assumptions and any stated availability targets.
  • Assurance: applicable independent reports or tests actually available; a contractually agreed way to answer reasonable security questions.

No SOC 2, ISO, HIPAA, universal privacy-law compliance, guaranteed uptime or recovery-time certification is claimed by this policy. Any service-level target, audit right, testing scope and remediation expectation belongs in the relevant agreement and must match the controls that can actually be delivered.

11

The data-processing schedule for an engagement

Before relevant private information is connected, the parties should complete and accept a schedule covering the following. This is a substantive contracting requirement; the list itself is not a signed DPA.

Required entryWhat the agreement must settle
Instructions and rolesIdentify the client, Prospera and relevant provider roles; define the service purpose, duration and documented instructions. No unrelated use of the data is authorized.
People and informationSpecify categories of people and records, sensitive-data exclusions, collection basis and allowed sources. Identify the authoritative record owner.
Safeguards and confidentialityIdentify authorized personnel, confidentiality obligations, access controls, client separation, host security measures and the evidence available to review them.
Providers and transfersName authorized providers, locations and relevant restrictions, onward-processing terms and the review process for material changes.
Requests and incidentsAssign cooperation for access/correction/deletion requests, incident assessment and notification, with response contacts and agreed timing.
End of processingSpecify export/return, deletion, backup and legal-hold exceptions, transition assistance, applicable charges and completion evidence.
Accountability and changeSpecify reasonable information or assurance rights, handling of a disputed or unlawful instruction, material change approvals and any region-specific contract terms.

Unresolved requirements must be settled or explicitly excluded before the affected service begins. A general website policy cannot silently substitute for a customer’s required security or processing agreement.

12

Technical review and privacy contact

Send questions about proposed data handling, provider restrictions, residency, security review or exit needs to cory@prosperarevops.com. Do not attach live records or secrets to an initial request. We can first agree the appropriate review and transfer method.

See Privacy & intake for individual requests, and Managed software & custom work for project, payment, IP, support and change responsibilities. The applicable signed agreement governs the service, subject to rights and duties that cannot lawfully be excluded.

QUESTIONS BEFORE YOU COMMIT?

Let’s make the responsibilities clear.

For a policy question, privacy request or a security concern, contact Cory. For an active service, use the contact and escalation route in your agreement.

cory@prosperarevops.com