This Is My URL is a one-person Canadian web practice based in Fort Erie, Ontario, owned and operated by Christopher Ross. This page describes how the site, its toolchain, and client engagements are operated from a security standpoint, what controls are in place, and what is not. Procurement teams comparing vendors should be able to read this and make an informed call without a discovery meeting.

Scope and posture

Two-column controls map of the security posture. Left column: four site-operations controls (WP Engine managed hosting with SOC 2 Type II, PCI DSS, and ISO 27001 certification at the hosting layer; weekly patch reviews with same-day response to exploitable vulnerabilities; daily managed backups with pre-deployment snapshots; minimal third-party surface limited to analytics, hosting, and email). Right column: five client-engagement controls (least-privilege access with editor or author roles preferred over administrator; staging-environment testing before production; data minimisation so real personal, payment, and learner data are not pulled into development environments; mutual NDAs and good-faith security questionnaires; complete credential revocation at engagement end). Centre bridge zone in gold borders: three shared practices spanning both lanes (TLS 1.2+ with HSTS and automated certificate rotation; 2FA plus credential vault discipline including 1Password on the client side; Git-based code workflow with PHPCS and PHPStan static analysis as the sole code-delivery channel). Below the columns, a dashed grey panel titled 'What is not in place' names four explicit limitations without alarm framing: no SOC 2 or ISO 27001 at the practice level, no 24/7 security operations centre, no published bug bounty programme, no standing penetration tests on the site itself. — Procurement security with explicit scope boundaries — and explicit honesty about what isn't in place.

This is a single-practitioner practice, not a SaaS platform. There is no internal team, no engineering org chart, no SOC 2 audit on file. The site, the toolchain, and the client engagements are operated to the standard a careful one-person WordPress practice can hold itself to: managed hosting on an audited platform, two-factor authentication on every administrator account, code review through Git, and the controls described below. The work that flows through here is WordPress development, audits, training, and editorial advisory. Procurement teams that require a formal third-party audit are told that in the first reply, not after a sales cycle.

How this site is operated

Managed hosting. Production runs on WP Engine, which holds SOC 2 Type II, PCI DSS, and ISO/IEC 27001 attestations at the platform layer. Their compliance posture is published at wpengine.com/legal/compliance.
Encrypted in transit. TLS 1.2 or higher on all connections, HSTS in effect, automated certificate rotation. No HTTP fallback.
Administrative access. Two-factor authentication is required on all administrator accounts. Credentials are unique per system and stored in a dedicated password vault. Credentials are never sent over email, Slack, or text message.
Code review and static analysis. Site changes ship through a Git workflow with PHPCS (WordPress Coding Standards) and PHPStan checks. Push to production is a deliberate, named action, never an automated promotion.
Patch cadence. WordPress core, plugins, and themes are reviewed weekly. Advisories from the WordPress vulnerability database trigger same-day review and, where exploitable, same-day patching.
Backups. Daily managed backups at the host level. Full snapshots are taken before any deploy with structural risk.
Minimal third-party surface. Only the analytics, hosting, and email subprocessors named in the privacy policy load on this site. No advertising networks, no behavioural pixels, no third-party tag managers, no fingerprinting scripts.
No payment data. This site does not process payments. Donations, when offered, are handled by an external processor; card data never touches this site or its host.

In client engagements

The same posture applies to client work, with adjustments per engagement.

Credential handling. Client credentials are stored inside the client’s chosen password manager, or in 1Password if the client does not have one. Credentials are never sent over email, Slack, or text message.
Least privilege. Editor or author access is requested where administrator is not required. Administrator access is removed at the end of the engagement.
Code delivery. Code is delivered through Git — the client’s repository, a private GitHub repository, or a private repository on the client’s host. Zip files over email are refused.
Staging first. Structural changes are tested in a staging or development environment before reaching production. Where the client lacks one, one is provisioned for the engagement.
Data minimisation. Real personal data, payment data, and student or learner records are not pulled into development environments. Where a flow needs realistic data to test, it is scrubbed or synthesised.
NDAs and questionnaires. Standard mutual NDAs are signed without negotiation. Vendor security questionnaires are completed in good faith and the answers do not invent capabilities the practice does not have.
End of engagement. Client credentials are deleted, repository access is removed, and any working copies of client data are erased. Confidentiality continues after the engagement ends.

What is not in place

Honesty matters more here than marketing copy, especially for procurement teams comparing vendors:

Not SOC 2, ISO 27001, HIPAA, FedRAMP, or PCI certified at the practice level. Those frameworks are designed for organisations with internal audit functions, dedicated security staff, and the headcount to separate duties; a one-person practice does not have the structure they assume. Procurement teams that require practice-level certification should select a vendor that holds it. The hosting and processor layers carry their own attestations where applicable.
No 24/7 security operations centre. Incidents are handled within business hours and as quickly as possible outside them. There is no on-call rotation. Engagements that require round-the-clock incident response should hire a firm with an audited operations team.
No published bug bounty. Vulnerability reports are read, acknowledged, and acted on, but there is no posted payout schedule.
No standing penetration test on this site. The scope does not warrant it. Client engagements that require a pen test are scoped to use a third-party tester, with their report shared in full with the client.

Reporting a vulnerability

If you believe you have found a security issue affecting this site or any plugin published from this practice, please report it before public disclosure. Coordinated disclosure is appreciated and good-faith research will not be subject to legal action from this practice.

Email: security@thisismyurl.com.
Acknowledgement target: within two business days.
Fix or mitigation target: within ten business days for confirmed issues, sooner for actively exploited ones.

Useful details to include: the affected URL or plugin, a clear description of the issue, reproduction steps, and the impact you observed.

Incident response

If a security incident affects this site or client data, the response follows four steps:

Contain. Revoke credentials, isolate the affected component, take a forensic snapshot if useful.
Investigate. Determine what was accessed, what was changed, and what data was involved.
Notify. Affected parties are notified promptly. For incidents involving personal information that create a real risk of significant harm, the affected individuals and the Office of the Privacy Commissioner of Canada are notified as soon as feasible, as required by PIPEDA, and a record of the breach is kept.
Remediate and document. A short post-incident note is shared with the affected client, including what changed in the response process to prevent a repeat.

Subprocessors and data residency

The list of service providers that process data on behalf of this site is published in the privacy policy. Hosting (WP Engine) and analytics (Google Analytics 4) are operated from the United States; data processed by those providers may be subject to lawful access requests in that jurisdiction, including under the US CLOUD Act. Contractual safeguards are in place where required. Public-sector buyers in jurisdictions with data-residency restrictions (Ontario FIPPA, BC FOIPPA, Nova Scotia PIIDPA, Quebec Law 25) should raise residency requirements at the proposal stage so a Canadian-hosted alternative can be priced in.

Accessibility and privacy

Security is one of three procurement table-stakes that this practice publishes openly. The other two are the privacy policy, which covers what data is collected and the rights you hold under PIPEDA, and the accessibility statement, which covers WCAG 2.2 conformance, testing methodology, and how to report a barrier.

Changes

This statement is reviewed at least once a year. Material changes are summarised in a short note at the top of the page for at least 30 days. The reviewer’s name and the last review date are stamped on this page by the site framework.

Contact

General security questions: security@thisismyurl.com. Other contact channels are listed on the contact page.