Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Almost every framework we work in names security awareness training directly, and PCI DSS goes as far as naming the topics it has to cover. The control is rarely failed because people were not trained. It is failed because nobody can produce dated, per-person records showing that they were.
Scope a programmeThe obligations differ in wording and in how prescriptive they are. What they share is that the evidence, not the training, is what gets sampled.
| Framework | Status | What it requires | Evidence expected |
|---|---|---|---|
| PCI DSS v4.012.6.1, 12.6.2, 12.6.3 | Required | A formal security awareness programme must exist. It must be reviewed at least once every twelve months and updated as needed to address new threats. Personnel must be trained on hire and at least once every twelve months. | Programme documentation, the annual review record, and per-person completion records with dates. |
| PCI DSS v4.012.6.3.1 and 12.6.3.2 | Required | Training must specifically cover phishing and related social engineering attacks, and the acceptable use of end-user technologies. These are named as separate sub-requirements, which is why generic packages often fail to satisfy them. | Content demonstrably covering both topics, not a general module that mentions them in passing. |
| ISO/IEC 27001:2022A.6.3 | Required | Personnel and relevant interested parties must receive appropriate information security awareness, education and training, plus regular updates of policies and procedures relevant to their job function. | Role-relevant content, delivery records, and evidence the material tracks your actual policies. |
| HIPAA Security Rule45 CFR 164.308(a)(5) | Required | A security awareness and training programme is required for all workforce members, including management. The implementation specifications cover security reminders, protection from malicious software, log-in monitoring and password management. | Training records for the whole workforce, plus evidence of ongoing reminders rather than a single annual event. |
| SOC 2CC1.4 and CC2.2 | Expected | The entity must demonstrate a commitment to attract, develop and retain competent individuals, and must internally communicate information, including objectives and responsibilities for internal control. | Training records and evidence that security responsibilities were communicated to the people who hold them. |
| GDPRArticle 39(1)(b) | Conditional | Where a data protection officer is appointed, awareness raising and staff training form part of the monitoring duties assigned to that role. | Evidence that privacy training reaches the staff carrying out processing. |
The sub-requirements are where this gets failed. PCI DSS 12.6.3.1 names phishing and social engineering, and 12.6.3.2 names acceptable use of end-user technologies, as separate obligations. A general security course that mentions phishing in one slide has not clearly satisfied either.
Built so the evidence falls out of running it, rather than being assembled the week before an audit.
Different content for engineers, for people handling customer data, and for everyone else. Frameworks ask for training relevant to the job function, and a single all-staff course is the most common reason this control gets a finding.
Training on hire and at least once every twelve months, tracked so the twelve months is measured per person rather than per calendar year. The per-person clock is what PCI and most auditors actually sample against.
Covered as its own module because PCI DSS 12.6.3.1 names it separately, with simulation where you want a measurable baseline rather than an attendance record.
The other named sub-requirement, tied to your actual acceptable use policy rather than a generic one, so the training and the policy do not contradict each other.
Where you are heading for PCI DSS or ISO 27001, engineering needs content its own auditors will recognise. This pairs with the independent code review requirement in PCI DSS 6.2.3.
Per-person, dated, exportable. This is the deliverable auditors actually sample, and it is the part companies running informal training cannot produce.
The documented review PCI DSS 12.6.2 requires, updating content against new threats so the programme does not quietly go stale between audits.
Training is one control in a set, and it is cheap relative to the rest. Where we are already running your SOC 2, ISO 27001 work, the curriculum is built against the policies we wrote, so the training and the policy set do not drift apart. That drift is the second most common finding after missing records.
Where somebody else is running your programme, this stands alone perfectly well. The same is true of our internal audit work, which we take on a ring-fenced basis for companies whose readiness was done elsewhere.
SOC 2 does not name it as a standalone control the way PCI DSS does, but CC1.4 and CC2.2 require the entity to develop competent people and to communicate internal control responsibilities to them. In practice every SOC 2 auditor asks for training records, and being unable to produce them is a straightforward way to pick up an exception.
PCI DSS requires it on hire and at least once every twelve months, with the programme itself reviewed annually. HIPAA requires it for all workforce members with ongoing security reminders rather than a single annual event. ISO 27001 says regular updates relevant to the job function without naming an interval, so you set the interval and then have to meet the one you set. Annual plus onboarding satisfies all of them.
Three things. A formal awareness programme must exist and be documented (12.6.1). It must be reviewed at least every twelve months and updated for new threats (12.6.2). Personnel must be trained on hire and at least annually (12.6.3), and the content must specifically address phishing and social engineering (12.6.3.1) and acceptable use of end-user technologies (12.6.3.2). Those last two are separate named sub-requirements and generic training often does not clearly satisfy them.
You can, and for some companies that is the right answer. What a platform gives you is content and completion tracking. What it does not give you is the mapping between its modules and the specific sub-requirements you are being audited against, a curriculum matched to your actual policies, or an answer when an auditor asks why your acceptable use training describes a policy you do not have. We work either way: we will build the programme on a platform you already own, or run it without one.
Per-person completion records with dates, the content itself, the annual programme review, and evidence that new starters were trained on hire. For PCI they will look for phishing and acceptable use content specifically. Most findings here are evidence problems rather than training problems.
Generally yes. HIPAA applies to the workforce, which includes people whose conduct you control regardless of whether you pay them as employees. PCI DSS applies to personnel with access to the cardholder data environment. ISO 27001 A.6.3 extends to relevant interested parties. Scoping training to full-time employees only is a common and easily-found gap.
It complements training rather than replacing it. Simulation gives you a measurable click rate and identifies who needs more support, which is genuinely useful. It does not by itself evidence that people were taught the material, so auditors will still ask for the training records behind it.
The requirement does not scale down, but the programme does. A ten-person company still needs training on hire and annually, still needs the phishing and acceptable use content if PCI applies, and still needs records. What it does not need is an enterprise learning platform. We scope it to the size of the company and the frameworks actually in play.
Free PDFs, no card
The IR plan template and the vendor security questionnaire as PDFs, plus the readiness checklists. Free, no card.
From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.
Track record
We would rather show you the work than a wall of logos. Here is what is behind the advice.
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
The printer is the one that matters on a compliance page: an asset nobody counts as a computer, on a flat network, downed by a device that never had to log in. Auditors ask how controls fail. We have found out first-hand.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.
The platform held 99.9% uptime throughout, which is the part most readiness projects get wrong: controls are easy to design and hard to retrofit onto a system people already depend on.
For a Waterloo data centre operator we ran SOC 2 Type II and ISO 27001:2022 together rather than one after the other, across a production campus, an AI compute platform and a self-hosted collaboration stack. Scoped so further Ontario and Quebec sites enter as they reach production. Findings delivered and remediated.
For an Ontario medtech company putting an AI clinical assistant in front of practitioners, we ran the gap analysis and built the evidence programme behind their SOC 2.