SREDr Security White Paper | Support

How SREDr protects your data Last updated: September 2026

Overview

SREDr helps companies prepare SR&ED tax credit claims by connecting to the tools your team already uses — issue trackers, repositories, and internal documents — and turning that work into audit-ready evidence and narratives, in partnership with your SR&ED consultant. Because that process touches sensitive engineering and business data, security, data minimization, and Canadian data residency are treated as first-class design requirements, not afterthoughts.

This document summarizes the technical and organizational safeguards SREDr uses to protect client data, at a level of detail intended to give your security or IT team confidence in our practices without disclosing internal implementation specifics.

1. Data Minimization by Design: Diffs and Metadata, Not Repository Clones

The SR&ED program evaluates the documented process of technological investigation — the hypotheses, uncertainties, experiments, and iteration behind your work — not your finished code, algorithms, or proprietary implementations. SREDr's data collection is deliberately scoped around that principle:

Diffs and metadata, not repository clones. When SREDr connects to a repository, it collects commit messages, pull request descriptions, code review discussion, and line-level differentials (diffs) — not full file contents or a repository clone. Diffs can include source fragments needed to understand the work; we do not store complete files or clone the repository.
Commentary and metadata only. Across all connected sources — issue trackers, documentation, and test systems — SREDr collects the narrative and process artifacts relevant to substantiating a claim (descriptions, comments, status history, test outcomes) rather than the underlying deliverables themselves.
Fixed retention periods. We keep claim information for the current tax year and the six preceding tax years, so it remains available for a CRA review and for later-year claims. We delete account and claim information within thirty days of a deletion request or account closure, except where the law requires us to keep it longer. Routine backups are overwritten within seven days.

2. Data residency

Claim information is stored and processed in Canada (AWS Montreal / ca-central-1):

The application database, including claim records, evidence, and encrypted tokens for systems you connect
File storage for uploaded evidence
Transactional email from the product
Conversion of uploaded payroll or tax documents to text (including scanned images)

What stays in the United States, by design:

Sign-in. Authentication (email, optional mobile number for SMS multi-factor, and session information) is handled by Amazon Cognito in the United States.
AI analysis and drafting. Requests are sent to Amazon Bedrock in the United States, processed, and returned. Content is not retained there after the request completes, and is not used to train models. No model we use is available in AWS's Canadian region today.

Domain name resolution and the content delivery network that serves the public site operate globally and do not store personal information at rest.

As a result, sign-in data and the content of an AI request may be subject to United States law, including lawful access requests. Claim data at rest is not.

3. Identity & Access Management

Managed authentication. Sign-in is handled by Amazon Cognito, a purpose-built identity provider used across the AWS ecosystem, rather than custom-built authentication code. Credential storage, password hashing, and token issuance follow AWS's hardened, independently audited implementation.
Strong password requirements. All accounts enforce minimum length and complexity requirements (uppercase, lowercase, numbers, and symbols).
Multi-factor authentication (MFA). SREDr supports both authenticator-app (TOTP) and SMS-based MFA, and can be configured as a requirement for administrators and consultants working on your claim.
Short-lived, signed sessions. Sessions use signed, httpOnly, secure cookies that are inaccessible to client-side scripts, reducing exposure to token theft via cross-site scripting.
Role-based access control. Every user — whether an administrator on your team, a team member contributing evidence, or your SR&ED consultant — is assigned a role that determines exactly which claims and actions they can access. Access is enforced on every server-side request, not just hidden in the UI, and is strictly scoped to your organization's own account, so another client's data is never visible to your users, and your data is never visible to them.

4. Data Encryption

Encryption in transit. All traffic to SREDr is served over HTTPS with modern TLS (1.2+), enforced at the network edge. Unencrypted connections are automatically redirected to HTTPS.
Encryption at rest. Client data is stored in a managed AWS database in Canada that encrypts stored data and automated backups using AWS-managed keys. Uploaded files use the same posture in Canadian object storage.
Application-level encryption for connection credentials. OAuth tokens and API keys for systems you connect are stored in the Canadian database as ciphertext. Each record is encrypted with AES-256-GCM. The wrapping key is held in AWS Key Management Service in the same Canadian region — it never sits in the database next to the tokens. Tokens are decrypted only in memory when a connection is used. They are not written to application logs.
No third-party passwords. We store tokens, not your Jira, GitHub, or similar account passwords.

5. Third-Party Integrations (Jira, GitHub, Linear, etc.)

OAuth-first connections. Where supported, SREDr connects to your tools using OAuth 2.0 — the same standard used by major SaaS platforms — rather than requesting your account password.
GitHub App, per repository. The preferred GitHub connection is a GitHub App installed on the repositories you choose, with read-only contents and metadata. It does not store a user access token. A remaining GitHub user-OAuth path is broader and is not the preferred connection.
Least-privilege scopes. Other integrations request the read-level access needed to gather process evidence (issues, commit history, pages, or Drive file revisions), not administrative control over your systems.
CSRF-resistant authorization flow. Each connection request is protected with a signed, single-use state token, preventing forged or replayed authorization attempts.
Revocable at any time. Connections can be disconnected from within SREDr or directly from the third-party provider's own security settings at any time, immediately halting further data access.
Tokens, not passwords, at rest. Only encrypted OAuth tokens are stored — never your underlying account credentials — and tokens are refreshed automatically rather than requiring long-lived static secrets.
As described above, what SREDr retrieves from these systems is itself minimized — diffs and commentary, not deliverables.

6. File Uploads & Evidence Handling

Uploaded documents (spreadsheets, CSVs, exports, office documents) are transferred directly to encrypted Canadian cloud storage using short-lived, single-use upload authorizations — files never persist on individual operator devices.
File type and size are validated before and during upload, with per-type size limits to prevent abuse.
Access to uploaded evidence is subject to the same role- and account-scoped authorization checks as all other data in the platform.
Payroll and tax documents. Where you upload a payroll record, pay statement, or tax slip, we convert it to text on our Canadian infrastructure and remove identifiers we do not need — including social insurance numbers, telephone numbers, and email addresses — before any part of it is sent for analysis. We do not store the document itself. We retain only the employee name, role, work location, compensation, and hours extracted from it.
Evidence retrieved from connected systems is scanned for common credential patterns before it is stored.

7. Cloud Infrastructure

SREDr is built entirely on Amazon Web Services, using managed database, container, identity, and AI services rather than self-managed servers — reducing the attack surface associated with unpatched operating systems or ad-hoc infrastructure.
The production application and claim-processing workers run as isolated containers in the Canadian region, talking to the Canadian database and file storage. Sign-in and AI inference call the United States services named in section 2.
Infrastructure is defined and deployed as code, which means every change to our production environment is version-controlled, reviewed, and repeatable — reducing the risk of manual configuration drift or undocumented changes.
System activity is logged to centralized cloud logging for operational monitoring and incident investigation.

8. Application Security

SREDr is built on Next.js Server Actions, which include built-in origin verification to mitigate cross-site request forgery (CSRF) on all data-modifying requests.
Authorization checks are enforced independently on every server-side operation, so access control cannot be bypassed by manipulating the client application.
Production builds strip debugging information and source maps, and administrative support access is itself permission-gated and restricted to designated internal roles.

9. Privacy & Compliance

SREDr's data practices are governed by the Personal Information Protection and Electronic Documents Act (PIPEDA) and applicable provincial privacy legislation. See our Privacy Policy for full details.
Your data is never used to train public/third-party AI models. AI processing is performed only on the process evidence described above, solely to deliver the analysis and drafting features your claim requires.
We do not sell client data, and disclosure to any subprocessor is limited to what is necessary to operate the service, under confidentiality obligations.
You may request deletion of your data. We delete account and claim information within thirty days, subject to the claim-retention window above and any longer period the law requires.

10. Shared Responsibility

Security is a partnership. We recommend:

Enabling MFA for all users with access to claim data.
Granting integration connections (Jira, GitHub, Google Drive, etc.) using the least-privileged account practical.
Promptly deactivating SREDr access for team members who leave your organization or change roles.

Questions?

We're glad to walk your security or procurement team through any of the practices above, or to complete a vendor security questionnaire. Contact us at security@sredr.com.

This document is provided for informational purposes to help clients evaluate SREDr's security practices. It is not a warranty or contractual commitment, and specific controls may be updated over time as our platform evolves. For contractual security or data-processing commitments, please refer to your Master Services Agreement or Data Processing Addendum.