Security & Data Handling

1. Control status

2. Identity and access

• Each request is authenticated and associated with a user and organization before protected data is returned.
• Owner, accountant, and member roles separate organization administration, review, and contribution workflows.
• Password reset revokes the user's current token generation and clears stored sessions.
• Authentication and password-reset routes are rate limited.
• Users can enable authenticator-app MFA after password confirmation. Setup expires after 10 minutes, backup codes are one-time use, login requires an MFA challenge, and disabling requires the password plus a current factor.
• SAML SSO, SCIM provisioning, domain verification, and conditional-access integration are not currently available.

Account owners should invite named users, apply the least-privileged role, review membership regularly, and remove users promptly. Shared accounts should not be used.

3. What customer content can contain

Depending on customer choices, the platform can hold Git commit metadata and text, Jira or Azure DevOps work items, Slack or Teams messages, employee attribution and timestamps, project and experiment descriptions, expenditure and personnel records, AI prompts, generated narratives, citations, reviews, and exports.

4. AI narrative data flow

1. The user chooses a model and evidence for a generation or improvement request, subject to the organization policy.
2. The enforced minimization policy builds context from project name, description, fiscal year, and technology stack; selected evidence IDs, sources, titles, summaries, dates, and tags; generation instructions; and draft narrative text when improving a draft. Evidence links and raw integration payloads are excluded.
3. The request is sent to Cohere, Anthropic, or OpenAI according to the selected model.
4. The returned draft is stored with the project for human review and editing.
5. The reviewer must validate statements and citations before approval or export.

A customer-supplied API key is used for that request and is not intentionally stored, but the prompt still goes to the selected provider. SR&ED Copilot does not use customer data to train its own model and relies on applicable provider API terms for provider training restrictions. See the Subprocessor Register.

An organization owner can allow hosted and customer-key requests, require customer-supplied keys, disable external AI entirely, and choose which of Cohere, Anthropic, and OpenAI are permitted.

5. Integration lifecycle and offboarding

1. An account owner reviews the requested scope and authorizes a connection.
2. OAuth tokens are stored with application-level authenticated encryption.
3. The Service fetches or receives supported records and stores the resulting evidence under the selected organization and project.
4. Before disconnecting, the owner sees provider-wide imported-evidence, citation, and narrative impact for the organization.
5. The owner explicitly chooses to keep imported evidence or permanently purge matching provider evidence. Purge is blocked while approved/submitted narratives rely on that evidence; affected draft/review narratives return to draft. The choice and impact counts are audited.
6. The connection credentials are removed and future access stops; the owner should separately review or revoke the provider-side connected-app grant.

For incident containment, disconnect the source, rotate or revoke the grant in the source system, review imported evidence, remove affected records, and contact hello@sredcopilot.ca. Disconnection alone is not erasure.

6. Data residency and transfers

A provider's Canadian headquarters does not by itself establish Canadian processing for a particular request. Customers with a hard residency requirement should not use the Service for covered data until a written, verified deployment arrangement is in place.

7. Incident response and notification

Reports are triaged through email; there is no public 24/7 security hotline today. After validating that a security incident may have affected customer data, we target notice without unreasonable delay and within 72 hours. We do not wait for complete forensic certainty if available facts support customer action. Applicable law or a signed agreement may require a shorter period.

The initial notice should include known scope, affected data or systems, containment, recommended action, and the next update time. Details may change as the investigation continues. See Service Commitments.

8. Retention, continuity, and export

New workspaces default to an 84-month conservative retention-planning window, while existing organization settings remain explicit. The setting flags older evidence and does not silently delete it. The Service is not the customer's statutory archive; retention mechanics still vary by record type, account status, delete actions, verified requests, and managed-provider backup rotation.

• Keep original commits, tickets, messages, approvals, payroll records, and other source records in approved systems.
• Export project preparer review binders after review milestones and before subscription cancellation.
• Organization owners can inspect a data inventory and download a sanitized JSON export covering customer records, decrypted portable claim-workspace data, and audit history without authentication secrets, OAuth tokens, or payment-provider identifiers.
• Confirm the organization's retention setting and do not assume it guarantees preservation or deletion on a particular date.
• Use a verified privacy request for account-level export or deletion needs not covered by product controls.

9. Assurance and roadmap

There is no SOC 2 Type II report, independent penetration-test report, formal security certification, or claim of certified PIPEDA compliance today. Public descriptions and a reasonable questionnaire response can support initial due diligence, but they are not independent assurance.