Security at JCO

How we protect the data our clients trust us with, and the site you are reading now.

Last updated October 18, 2026

Overview

We build systems that touch credit files, bank statements, CRM records and financial reporting. We treat that data the way a lender's risk team would expect: least privilege, logged access, encryption everywhere, and nothing kept longer than the work needs.

This page covers two things: how we run our own website, and how we handle client data on engagements. The specific controls for an engagement are written into its statement of work and, where applicable, a data processing agreement.

Infrastructure and hosting

This website runs as a container on Google Cloud Run in the us-east1 region. Secrets are held in Google Secret Manager and injected at runtime, never committed to source code or baked into images.

For client engagements we deploy in one of two ways, chosen with you during scoping:

• Inside your environment. The system runs in your cloud account, under your identity provider, logging and network controls. We work through access you grant and can revoke at any time.
• A dedicated environment. A cloud project provisioned for your engagement alone, never shared with another client, and transferable to you at handoff.

Our primary infrastructure provider is Google Cloud. Where a client standard requires it, we build on [other providers supported, e.g. AWS or Azure: confirm].

Data handling and encryption

• In transit. All traffic to this site is served over HTTPS, and we send HTTP Strict Transport Security (HSTS) with a one-year max-age covering subdomains. Integrations we build use TLS for every hop.
• At rest. Data stored on Google Cloud is encrypted at rest by default. Where a client requires it, we use customer-managed encryption keys through Cloud KMS [confirm CMEK is offered].
• Minimization. We request only the data a workflow needs, prefer samples or masked data during build, and keep production data inside the production environment.
• Retention. At the end of an engagement, client data held in JCO-controlled environments is returned or deleted on the schedule set in the statement of work [default deletion window, e.g. 30 days after handoff].
• Ownership. Your data stays yours. Code, prompts, documentation and runbooks transfer to you at handoff.

Access control

• Access to client systems is granted per person, per engagement, and limited to what the work requires.
• We use named accounts with multi-factor authentication. We do not share credentials.
• Access is reviewed during the engagement and removed at handoff, or sooner on your request.
• Everyone who works on an engagement, including members of our fractional bench, is bound by written confidentiality obligations before receiving access [confirm contractor NDA and background-check practice].

Application security

For this website:

• Every response carries security headers: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY and a strict-origin referrer policy.
• Form endpoints validate and size-limit input, reject oversized payloads, use a honeypot field against bots, and are rate limited per IP address.
• The site has no user accounts and serves no third-party scripts on its core pages.

For systems we build, our standard practice includes code review before merge, dependency management, secrets kept out of source control, input validation at every boundary, and decision logs so automated outcomes can be replayed and audited months later.

AI and model data use

• Client data is never used to train models. Not ours, not anyone else's.
• When a system calls a third-party model, we use API offerings whose terms exclude customer inputs from model training, and we configure the shortest retention the provider allows [confirm zero-retention arrangements per provider].
• Prompts, model choices and limits are documented and handed over, so your risk team can review exactly what the system does.
• Automated decisions that affect people, such as credit decisions, are designed with human review points and logged rationale.

Incident response

If we become aware of a security incident affecting client data, we will contain it, investigate, and notify the affected client without undue delay [contractual notice window, e.g. within 72 hours]. We will share what happened, what data was involved and what we are doing about it, and we will support any notification you are required to make. Incidents involving personal information are also handled under our Privacy Policy, including notification to regulators where the law requires it.

Compliance and questionnaires

• Diligence-ready. We accept NDAs and complete security questionnaires as standard. Completed questionnaires and this page's supporting detail are available on request.
• Privacy law. We handle personal information in line with PIPEDA, Quebec's Law 25 and, where applicable, the GDPR. See our Privacy Policy.
• Your standards. When an engagement runs inside your environment, it inherits your controls, and we follow your policies.

Subprocessors

These are the third parties that process data for this website and our own operations. Engagement-specific providers, such as a model API, are listed in the statement of work.

[Confirm this list is complete, e.g. model providers, accounting, Google Ads]

Reporting a vulnerability

If you believe you have found a security issue in this site or in anything we operate, email security@johnnychen.co. Please include enough detail for us to reproduce it, give us reasonable time to fix it before disclosure, and do not access data that is not yours. We will acknowledge your report and keep you updated. We do not take legal action against good-faith research that follows these guidelines.

For security questionnaires and diligence requests, contact the same address or johnny@johnnychen.co.