Security Consulting

On the application side the review works through the standard classes of failure against the real codebase rather than a checklist in the abstract: broken access control and object-level authorisation, authentication and session handling, injection and output encoding, cryptographic and secrets handling, security misconfiguration, outdated and vulnerable dependencies, and whether anything is being logged that would let you reconstruct an incident afterwards. Authentication gets particular attention, because it is where the highest-consequence mistakes cluster and where recovery flows — password reset, email change, support-initiated access — quietly undo the protections the login form implements properly. On the infrastructure side: remote access, firewall posture, patching discipline, transport and certificate configuration, secret storage and rotation, and backups, which are only worth what a tested restore proves they are worth. On the marketing side, the container itself is treated as code: what is in it, who can publish to it, what each vendor script can reach, whether customer data is being passed to platforms that were never meant to receive it, and whether the consent configuration matches what actually fires. That last part carries legal exposure as much as technical exposure, and for a Canadian business it lands under privacy and anti-spam law rather than only under a security policy. Findings arrive severity-rated with reproduction steps and a remediation plan, and where the work includes fixing them, the fixes get retested rather than assumed. I run the same review cadence against the systems I operate, which is mostly how I learned that the second audit finds the things the first one taught you to look for.