Technology · 10 Security & Compliance
Every OlDevs project ships with threat modelling, OWASP ASVS checks, encrypted data, single sign-on and audit logs as standard, plus the documentation your auditors, insurers and enterprise buyers will ask for. Here is how we decide what each build needs.
Updated September 2026 You own everything Reply within one business day
Portal
1,284
Members
99.9%
Uptime
0
Access issues
OlDevs, a full-stack studio in Vancouver, treats security and compliance as build requirements, not a final audit.Every project starts with a threat model, follows OWASP ASVS controls, and ships with encryption, SSO, MFA, role-based access and audit logs, with PIPEDA, Law 25, HIPAA or PCI DSS obligations mapped to features before coding starts. Clients receive the evidence: threat models, SBOMs, penetration test reports and a control matrix for SOC 2 or ISO 27001.
Key facts
10 · Security & Compliance
Each pattern below is a real decision on a real project, with the ongoing cost stated plainly so you can weigh it against the risk it removes.
Right for any project that handles personal data or money. We run a STRIDE-style session at kickoff and again when the architecture changes, then wire OWASP ASVS checks into code review and CI. Later cost: an hour or two per major feature to keep the model current.
Right when you ship to enterprise customers, regulated sectors or anyone who will ask what is inside the software. We generate a CycloneDX SBOM on every release, pin and scan dependencies, and sign container images. Later cost: a monthly patch cadence someone must own, and some breaking upgrades you cannot postpone.
Right when your users live in Microsoft Entra, Google Workspace or Okta, or a buyer's questionnaire demands SSO. We integrate OIDC first and SAML where a customer insists, enforce MFA, and offer passkeys for consumer logins. Later cost: identity provider licences and support when a customer rotates certificates.
Right for any system with two or more user types, and essential wherever an auditor may ask who saw a record and when. We define roles with you, enforce them server-side, and write append-only audit events to storage the app cannot rewrite. Later cost: log retention fees and discipline to stop roles sprawling.
Right everywhere, no exceptions. TLS 1.3 in transit, AES-256 at rest with keys held in a cloud KMS, field-level encryption for health or payment data, and secrets pulled from a vault rather than committed to config. Later cost: key rotation runbooks and a vault bill, both small next to a breach notification.
Right before any public launch, after major changes, and annually where SOC 2, PCI DSS or a customer contract requires it. We fix findings from our own testing first, then commission an independent test and hand you the report. Later cost: a yearly test budget and a rehearsed incident plan that names who calls whom.
Stack
Concrete tools, current at the time of writing; confirmed for your project at scoping.
Application security
Identity and access
Secrets and encryption
Supply chain and SBOM
Compliance and evidence
Monitoring and response
What changed
What moved in this area and what it means for your build.
Mar 2025
The requirements that were best practice until 31 March 2025 are now enforced, including inventories of payment-page scripts and tamper detection on checkout pages. For clients taking cards, this means we treat every script tag on a payment page as an audited asset and prefer hosted fields from the processor.
May 2025
The new edition reorganised the verification requirements and clarified what each level means. We rebased our review checklist on 5.0, so new projects are measured against the current standard while older codebases keep their 4.0 mapping until a scheduled refresh.
2025
Bill C-27, which would have replaced PIPEDA with the Consumer Privacy Protection Act, died when Parliament was dissolved in early 2025. PIPEDA and provincial laws remain the operative rules, and Quebec Law 25 is the strictest of them, so we design to Law 25 whenever a client has Quebec users.
2025 to 2026
A wave of state laws took effect through 2025 and into 2026, with varying thresholds and consumer rights such as universal opt-out signals. For a Canadian company selling into the US, we build consent, deletion and opt-out flows once, driven by configuration rather than per-state code.
Apr 2026
The US Department of Justice rule required larger state and local government web content and apps to meet WCAG 2.1 AA by April 2026, with smaller entities following in 2027. Any vendor selling to US public bodies now needs an accessibility conformance report, which our WCAG 2.2 AA baseline already covers.
2026
Browser and platform support for passkeys is now broad enough that we offer them by default on consumer logins, with password plus MFA as the fallback. Clients see fewer credential-stuffing incidents and fewer password reset tickets, at the cost of a slightly more involved account recovery design.
How we choose
A control nobody operates decays. We match the depth of tooling to the team that will own it: a two-person IT group gets managed services and alerts routed to one inbox; a full security team gets raw logs, SIEM integration and the option to run its own scanners.
Canadian residency is straightforward on the big three clouds, but supporting services often are not. We map every place data lands before choosing vendors, and for BC public bodies we follow FOIPPA's privacy assessment requirements from the start.
We list the data you collect, tag each field with the statute that governs it (PIPEDA, Law 25, HIPAA, PCI DSS), and let that drive design. Consent screens, retention timers and deletion jobs are features with owners, not clauses in a policy.
Every control has an ongoing cost in time, licences and friction. We state it plainly and choose the smallest set that closes the risks in the threat model, then leave a documented path to add more when a contract or audit calls for it.
If enterprise sales are in your plan, we read the questionnaires your prospects use before we design, so SSO, audit logs and data handling answers are true by construction rather than promised for a future release.
We assume a breach will happen somewhere and design so it stays small: tenant isolation, least-privilege service accounts, short-lived credentials and immutable logs. The question is never whether a control is fashionable, only how much damage it prevents.
Who it's for
Whether the audience is a customer, a member, a citizen, or your own team, the choice has to hold up under real use.
Enterprise procurement arrives with a security questionnaire, an SSO requirement and a request for your SOC 2 report. We build so the honest answer to most of those questions is yes, integrate with Entra ID or Okta, and supply the control matrix your GRC team maps into its own framework.
Public bodies and member organisations handle personal data under FOIPPA, PIPEDA or provincial statutes and are often the first to be measured against AODA, the Accessible Canada Act or ADA Title II. We pair privacy impact assessments with WCAG 2.2 AA delivery and Canadian data residency where required.
One platform, many operators, and a head office that is liable for all of them. We use tenant-isolated data, per-location roles, centrally enforced MFA and audit trails that show which franchisee touched which customer record, so a problem at one site stays at one site.
Investors and early enterprise customers ask about security long before you can justify a security team. We give you the ASVS baseline, SBOM and pen test evidence to answer the first due-diligence round, and a SOC 2 readiness path you can start when the deals call for it.
Related technology
Modular monolith or microservices, queues or direct calls, one tenant or many: the shape of a system decides…
Explore05AWS, Microsoft Azure and Google Cloud, plus Vercel and Cloudflare where a smaller footprint fits. Canadian…
Explore06Your database outlives every framework in front of it. We default to PostgreSQL, add Redis, document stores,…
ExploreFAQ
Only if your customers ask for it, and many enterprise and US buyers do. SOC 2 is an audit of your organisation's controls, not a property of the code, so we cannot make you certified. What we can do is build the application and infrastructure so the technical controls (access, logging, encryption, change management) already exist and are documented, which removes most of the engineering work from a later Type I or Type II audit.
Yes. We deploy to Canadian regions on AWS, Azure or Google Cloud when residency matters, and we check where every supporting service, from email delivery to error tracking, actually stores its copies. Residency is a legal and contractual question as much as a hosting one, so we document the full data map rather than pointing at one server location.
Compliance attaches to the organisation holding the data, so the accurate statement is that we build systems that let you meet HIPAA or PHIPA obligations. That means signed business associate or service provider agreements where required, encryption and access logging for health records, minimum-necessary data flows, and breach procedures written into the incident plan.
A threat model and its decisions, a CycloneDX SBOM for each release, dependency and container scan results, the independent penetration test report with remediation notes, an architecture diagram showing data flows and trust boundaries, a control matrix mapped to ASVS and the frameworks you care about, and runbooks for key rotation, access review and incident response. Everything sits in your repository, not ours.
That depends on the support arrangement, and we settle it before go-live rather than during an incident. The plan names roles on both sides, notification timelines under PIPEDA, Law 25 or the US state laws that apply to you, and where logs live so investigation is possible. If you keep us on for support, we take the technical response; if not, your own team has the runbook.
Increasingly, yes. Ontario organisations fall under AODA, federally regulated ones under the Accessible Canada Act, and anyone selling to US public bodies is affected by the ADA Title II web rule. We build every project to WCAG 2.2 AA regardless, test with assistive technology, and can supply an accessibility conformance report for procurement.
We treat model providers like any other processor: data minimisation before a prompt leaves your system, contractual no-training terms, regional endpoints where available, and logging of what was sent. For sensitive workloads we can run open-weight models inside your own cloud account so nothing leaves it. Prompt injection and output handling are part of the threat model, not an afterthought.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with recommended platforms, structure and a tailored quote — no obligation.