Assignment evidence
Audience, assignment date, learning objective, content version, delivery status, access problems, and approved exclusions.
SOC 2 applies within a broader governance, risk, security, or privacy context for service organizations preparing controls and evidence for a SOC 2 examination. SOC 2 is an AICPA reporting framework based on the Trust Services Criteria. It is not a law or a product certification, and the controls and evidence examined depend on the service organization's system description, commitments, criteria, risks, and control design.
This guide explains how employee learning, phishing drills, reporting practice, and activity records may support that wider program without treating a training platform as proof of compliance.
Official-source context • Training workflow • Evidence planning • No compliance guarantees
SOC 2 is an AICPA reporting framework based on the Trust Services Criteria. It is not a law or a product certification, and the controls and evidence examined depend on the service organization's system description, commitments, criteria, risks, and control design.
Security awareness assignments, completion records, role-based learning, phishing exercises, reporting practice, and remediation records may support controls selected by a service organization, but the service auditor evaluates whether the relevant controls are suitably designed and, for a Type 2 examination, operated effectively over the review period.
Start with the current official text and the organization's own legal, regulatory, audit, risk, privacy, and security analysis. Product marketing, a generic checklist, or another organization's control mapping is not a substitute for that determination.
Source: AICPA & CIMA: SOC 2
| Program element | Question to resolve | Evidence to retain |
|---|---|---|
| Applicability | Which entities, systems, people, services, and obligations fall within the organization's SOC 2 scope? | Approved scope, owners, dependencies, exclusions, and source references. |
| Risk and behavior | Which workforce decisions support identified risks, policies, and controls? | Risk-to-behavior mapping and approved learning objectives. |
| Audience | Who needs a common foundation, role-based depth, privileged-user training, or contractor coverage? | Audience logic, assignment records, exclusions, and exception handling. |
| Evaluation | How will the organization review participation, practice, reporting, response, and improvement? | Defined measures, limitations, findings, owners, due dates, and review records. |
Use the current official source and qualified internal or external advisers to define applicability, accountable owners, workforce groups, systems, and required evidence.
Translate risks and policies into observable employee actions, such as verifying a payment request, protecting authentication factors, or reporting an unexpected document.
Assign accessible learning and, where authorized, use a controlled phishing simulation, cyber drill, reporting walkthrough, or tabletop to practice the behavior.
Reconcile audience, access, completion, exercise context, verified reports, response handling, exceptions, and completed improvements according to approved retention rules.
Source: NIST SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Program
Audience, assignment date, learning objective, content version, delivery status, access problems, and approved exclusions.
Started, completed, overdue, and inaccessible counts with dates and a documented exception process.
Authorized audience, scenario, delivery, unique events, verified reports, response handling, follow-up, and operating context.
Employee feedback, process findings, corrective actions, owners, target dates, completion, and management review.
Do not claim that a course, simulation, completion rate, certificate, or product purchase makes an organization SOC 2 compliant. Do not describe an activity as required unless the applicable current source and qualified analysis support that statement for the organization.
A simulation observes selected employee events under controlled conditions. It does not test every administrative, technical, physical, governance, privacy, incident-response, third-party, or operational control in the relevant program.
Provide reviewers with the actual records, scope, method, limitations, and follow-up. The relevant regulator, auditor, assessor, certification body, supervisory authority, customer, or other reviewer determines whether evidence is sufficient for its purpose.
Common questions about Phishmake's features, onboarding, and support, answered to help you get started with confidence.
No. Phishmake provides training, simulation, activity, and reporting workflows. It is not a regulator, auditor, certification body, supervisory authority, or law firm, and product use does not establish compliance.
Do not infer a universal schedule from this page. Timing depends on the current applicable text, organizational scope, risk assessment, policies, role changes, incidents, contractual duties, and reviewer expectations.
They may support evidence that an authorized exercise occurred and was reviewed. Retain audience, scenario, delivery, event definitions, reporting, response, follow-up, and limitations; acceptance remains with the relevant reviewer.
Verify the current official SOC 2 materials, organizational applicability, local or sector-specific rules, contractual requirements, and advice from qualified legal, compliance, audit, privacy, and security professionals.
Use Phishmake to organize employee learning, controlled phishing exercises, activity evidence, and documented follow-up without overclaiming the outcome.