You own your content. We use it to deliver your pack and your private AI partner — and we design our workflow to keep client work logically separated, access-controlled, and encrypted.
✓ Ownership & purpose
- We don’t sell client data or share raw content across clients.
- We keep initiatives separated so Project A doesn’t mix with Project B.
- We ask for only what’s needed to deliver a high-quality pack.
🔒 Security by default
- Encrypted transport (HTTPS/TLS) and encrypted storage where supported by our providers.
- Project-level separation in workflow and storage.
- Controlled internal access for delivery and QA only.
🤖 Your private AI partner
- Project-scoped context (your docs + your deliverables).
- No cross-client “sharing” of knowledge.
- Conversation logs may be retained for QA/safety (protected like other client data).
🧩 De-identified learning (internal)
- Examples: frequency of risk types, governance patterns, common KPI structures, schedule shapes.
- We remove direct identifiers (names, emails, org/project IDs) and avoid storing raw text as training data.
- If you require stricter handling for procurement or policy reasons, we can align via contract and workflow.
1) Data ownership & usage
What we use, what we don’t, and why.
⌄
✓ What we do
- Use your documents and survey responses to produce your pack deliverables.
- Use your project context to configure your initiative’s private AI partner.
- Keep projects separated so your data is not mixed across initiatives.
⛔ What we don’t do
- No selling of client data. No ad-tech use. No “data brokerage.”
- No sharing your raw project content with other clients.
- No using raw inputs to train a shared public AI model.
Note: When third-party AI infrastructure is used, we choose configurations and contractual terms intended to prevent your content from being used to improve their general models.
2) Your private AI partner
How it stays scoped to your initiative.
⌄
Your AI partner is built around your initiative’s context and the deliverables we produce for you. It is not trained on other clients’ data and is not designed to “learn” across organizations.
🧠 What it can access
- Your project docs and structured intake (within your initiative scope).
- Your pack deliverables (plans, maps, requirements, governance, reporting artifacts).
- Your team’s questions within that project context.
🛡️ Controls
- Project-level separation and access control.
- Shareable access only within your organization (you control who gets the link).
- Logs may be retained for QA/safety; handled like other client data.
3) De-identified learning & internal improvement
How we improve without using your raw content as training data.
⌄
Over time, we improve our templates, automation, and internal methods. To do this responsibly, we may retain de-identified, aggregated patterns derived from delivery — not your raw project content.
🧩 What “de-identified” means here
- Direct identifiers removed (names, emails, org/project IDs).
- Stored as patterns/signals (counts, labels, structures), not raw client narratives.
- Used internally to improve consistency and speed of delivery.
📌 Examples of retained patterns
- Common risk categories and controls themes.
- Recurring governance structures and decision-gate shapes.
- KPI categories and reporting rhythms across initiatives.
If your procurement process requires stricter handling (e.g., strict retention limits or specific data residency), tell us up front and we’ll align delivery workflow and contract terms accordingly.
4) Where your data lives
Encryption, separation, and cloud posture.
⌄
We use reputable cloud infrastructure and secure transport to store and process your project content. Content is separated by client and initiative to prevent cross-mixing.
🔐 Encryption
- HTTPS/TLS for transport.
- Encrypted storage where supported by our providers.
- Access control to reduce exposure.
🗂️ Separation
- Logical separation by client and initiative.
- Project A content is not visible inside Project B workflows.
- Scoped access for delivery roles only.
5) Internal access & operations
Least-privilege by default.
⌄
Internally, access to raw client inputs is limited to what’s required to produce and validate deliverables. We aim to keep access surfaces small and auditable.
👤 Least-privilege
- Only a small delivery team can access project inputs.
- Role-based access aligned to delivery responsibilities.
- Confidentiality obligations for anyone on the project.
🧾 Operational hygiene
- Strong authentication and secure access practices.
- Controlled sharing and separation of workspaces.
- Focused collection: we don’t ask for unnecessary sensitive data.
6) Retention
Time-bound storage to support delivery and follow-ups.
⌄
We retain project content for a defined support window so we can handle clarifications, regenerations, or add-ons without asking you to resend everything. After that window, content is deleted or archived per policy/contract.
⏳ Typical window
- Standard support retention is typically 12–24 months unless contract terms specify otherwise.
- If you require shorter retention, we can align via onboarding and written terms.
- Derived de-identified patterns (Section 3) may be retained to improve internal methods.
7) Third-party services
Infrastructure providers used to deliver the service.
⌄
We rely on a small set of specialized providers for secure intake, storage, and AI infrastructure. We select for strong security programs and data-protection commitments — and we avoid ad-tech in delivery flows.
A list of core sub-processors can be provided on request (and included in procurement/security documentation if needed).
8) Compliance posture
Best-practice controls we design around.
⌄
Our controls are designed around common security best practices: encryption, access control, separation of client data, and retention discipline. We can support security questionnaires and addenda as part of onboarding.
- Encryption in transit and (where supported) at rest.
- Access control + least-privilege principles.
- Client/initiative separation in workflow and storage.
- Logging/monitoring of key systems where available.
- Documented retention approach and onboarding alignment for stricter requirements.
9) Your responsibilities
How to keep risk low on your side.
⌄
You can help keep risk low by sharing only what’s needed and controlling internal access to deliverables and AI links.
🧼 Share only what’s needed
- Avoid unnecessary sensitive personal data in uploads unless essential.
- Redact or omit details you don’t want processed.
- If unsure, ask before sending.
🔑 Control access
- Share AI links only with authorized colleagues for the initiative.
- Use strong identity controls on your side (MFA/SSO where available).
- Keep internal distribution aligned to your policy.
10) Security review & procurement support
Questionnaires, addenda, and data residency discussions.
⌄
If you have procurement requirements (data residency, retention limits, security addenda, or vendor questionnaires), we’ll walk through them during onboarding and align delivery workflow where possible.