Security awareness training for SOC 2: what auditors expect

Why auditors look for security awareness training in SOC 2

Many security incidents start with a person: a convincing phishing email, a reused password, a customer export sent to the wrong address. Security awareness training shows that everyone who works for you knows the basics and what to do when something looks wrong. In a SOC 2 audit, it is a control auditors expect to see almost every time.

The Trust Services Criteria don't prescribe a training course, but two of the Common Criteria are usually met in part through training:

• CC1.4 covers attracting, developing and keeping competent people. Training people on the security responsibilities of their role is part of developing that competence.
• CC2.2 covers communicating internal control information inside the organization, including people's responsibilities for security. A training session is one of the clearest ways to show that communication happened.

How your auditor tests it depends on what your own policies and control descriptions say. A typical control reads something like "All personnel complete security awareness training on hire and annually thereafter." The auditor then asks for the material, checks that it was delivered, and samples people (often including new hires from the audit period) to confirm each one completed it on time. Whatever you write into the control is what you will be held to.

What a good program covers at a small company

You don't need a long course. You need material that matches the real risks of your business and the tools your people use every day. For most startups and small companies, a solid core looks like this:

• Phishing and social engineering. How to spot a suspicious email, message or call, fake login pages, urgent payment requests, and requests to share codes or credentials. Use examples that look like your own tools.
• Passwords and multi-factor authentication. Using a password manager, never reusing passwords, turning on MFA everywhere it is offered, and never approving an MFA prompt you didn't start.
• Device security. Screen locks, disk encryption, timely updates, what to do with a lost or stolen device, and the rules for personal devices.
• Data handling and classification. What counts as confidential or customer data at your company, where it may be stored and shared, and how to dispose of it.
• Reporting incidents. Exactly how to report something suspicious, who to tell, and the message that reporting quickly is always the right call, even when it turns out to be nothing.
• Acceptable use. A walk through the main rules in your Acceptable Use Policy and Code of Conduct, so the policies people acknowledge aren't abstract.
• Role-specific training. Engineers need more: secure coding basics, handling secrets and keys, code review expectations and safe use of production access. People with admin rights or access to customer data may need their own short module too.

Refresh the material each year with what actually happened: a reported phishing attempt, a near miss, a new risk from your risk assessment. Real examples stick better than generic ones.

Annual security training: how often and when

The most common pattern is on hire and at least annually. New starters complete training within their first few weeks, and everyone repeats it once a year. Some teams add short refreshers through the year, such as a quarterly reminder or a session after a notable incident.

There is no fixed SOC 2 deadline for any of this. Your Human Resources Security Policy or Information Security Policy sets the rule, and the audit tests that rule. Pick timing you can actually meet. "Within 30 days of start" is easy to defend if you hit it; "on the first day" is a promise that one late laptop delivery can break.

Training formats that work for small teams

Any format works if people actually complete it and you can prove they did. Common options:

• Live session. A 45 to 60 minute call or meeting, ideally with questions. Good for small teams and for culture. Record attendance from the meeting, not from memory.
• Recorded session. Record the live session and use it for people who missed it and for new starters through the year. Track who watched it and when.
• Short modules. Ten-minute lessons, often with a short quiz at the end. Easy to fit around work and easy to assign to new hires.
• Phishing simulations. Practice emails that look like real phishing, with a short explanation for anyone who clicks. Useful as a supplement that tests behavior, but usually not a replacement for the training itself.

What security awareness training evidence to keep

Auditors test what they can see. For each year's training, keep these together in one place:

1. The material. The slides, recording link, module list or a written outline, so the auditor can see what was covered and that it matches your policy.
2. The date or window. When the session was held or when the training was open, and the deadline you set.
3. The completion roster. Who was required to complete the training (everyone in scope at the time, including contractors with system access if your policy includes them) and the date each person completed it.
4. Follow-up for people who missed it. Reminders, escalations to managers, and a recorded reason and new date for anyone who couldn't complete it, such as a person on leave.
5. New joiners. For people who started during the year, the date they joined and the date they completed training, so the auditor can check your "within N days" rule.

The roster is the part that matters most. "We did a session in March" is not evidence. A list of names, required versus completed, with dates, is. For how to organize this alongside your other evidence, see SOC 2 evidence collection.

A simple annual training plan

Here is an example plan for a company whose fiscal year runs from January to December. Shift it to your own year and calendar.

The 30-day window here is only an example. Use whatever your policy says.

How training relates to policy acknowledgements

Training and policy acknowledgement are two separate controls that support each other, and auditors usually test both.

• Training shows people were taught what the risks are and how to behave. Its evidence is the material and the completion roster.
• Policy acknowledgement shows each person read and accepted a specific version of a specific policy, such as the Acceptable Use Policy. Its evidence is a per-person, per-version record.

Many teams time them together: the annual session walks through the key policies, and people acknowledge any that changed straight afterwards. Keep the records separate, though. A training roster doesn't prove someone accepted version 4 of a policy, and an acknowledgement doesn't prove they sat through training. For the acknowledgement side, see policy acknowledgement tracking for SOC 2.

Common mistakes

• No roster. A calendar invite is not a completion record. Track who was required and who finished.
• Forgetting new hires. The annual session goes well, but three people who joined in spring never trained. Audit samples often catch exactly this.
• Promising more than you do. A policy that says "quarterly training" when you train once a year creates an exception. Write the rule you actually follow.
• Leaving out contractors. If they have access to your systems or data, decide whether they are in scope and write it down.
• No follow-up record. People who missed the deadline were chased by direct message and nobody kept it. Record reminders and exceptions where the evidence lives.
• Evidence scattered across tools. Material in one drive, attendance in a chat thread, the roster in someone's spreadsheet. Put it in one place per year.

Running security awareness training in Confluence

If your compliance program lives in Confluence, Compliance in a Box treats training as a recurring activity, alongside policy acknowledgements. The training itself happens however you choose to run it. The app makes sure it is scheduled, evidenced and signed off every year.

An annual activity with its own evidence page

When you set up SOC 2, Security Awareness Training is created as one of the recurring activities, with an annual cadence and mapped to CC1.4 and CC2.2. Its activity page sits under Recurring Activities in the compliance space and holds the procedure to follow. Periods follow your fiscal year, and each is due on its last day.

Ahead of each due date (14 days by default), the app's daily run creates that year's evidence page under the activity page. It starts with a checklist and a section for each item: Training material and Completion roster. You write in the sections and attach the slides, recording details, roster exports and follow-up notes. Only the activity owner and Compliance Admins can edit it. If you run your session earlier in the year, a Compliance Admin can use Edit schedule to set up to 90 days of notice, so the page is there when you need it. See Evidence pages in the user guide.

An owner, approvers and reminders

Compliance Admins assign the activity's owner and approvers under Settings > Owners & approvers. With reminders on (the default), the owner gets a Confluence task when the evidence page opens, again 3 days before the due date, and weekly while it is overdue. When the evidence is complete, the owner selects Submit for approval from the page's Compliance byline item, and every approver must approve. The approval is tied to the exact page version submitted, and approving evidence you own is flagged as a self-approval, so choose an independent approver. See Owners and approvers and when reminders are sent.

Each year's period, with its status, submission rounds and a link to the approved evidence page version, also appears in the generated Activity Completion Report for your auditor.

Acknowledgements alongside training

The Acceptable Use Policy, Code of Conduct and Information Security Policy are among the policies that ask employees to acknowledge them. When a policy is first approved, or a later version is approved as a Material change, everyone in its audience is asked to acknowledge the approved version within 30 days, and new joiners are picked up by a daily check. So the policy side of your annual cycle is tracked per person, while the training evidence page holds the roster. See how acknowledgement campaigns work.

FAQ

Is security awareness training required for SOC 2?

The criteria don't name a specific training program, but training is one of the most common ways to meet the competence and internal communication criteria, and auditors expect to see it. In practice, plan on having it.

How often should employees complete security awareness training?

On hire and at least once a year is the common pattern. Your own policy sets the rule, and the audit tests against it.

Do phishing simulations count as training?

They are a useful supplement that tests real behavior. Most teams still run regular training and use simulations alongside it. Ask your auditor if you plan to rely on them heavily.

← All articles