Security Training Policy

Effective Date: [Effective Date] Version: [Version Number] Approved By: [Approver Name, Title] Owner: [Policy Owner Name, Title]

1. Purpose

This policy establishes [Company Name]'s requirements for providing security training to all personnel who can affect the security of company systems, customer data, or the confidentiality, integrity, or availability of company information. The policy exists to reduce the risk of security incidents caused by human error, to ensure consistent application of secure practices across the organization, and to satisfy training requirements under SOC 2 Trust Services Criteria (CC1.4, CC2.2), ISO/IEC 27001 Annex A.6.3, and NIST SP 800-50.

2. Scope

This policy applies to:

• All full-time and part-time employees.
• Contractors, consultants, and temporary workers with access to company systems, source code, production data, or customer data.
• Interns, fellows, and volunteers with access to the above.
• Any third party granted access credentials to company systems, regardless of engagement type.

The policy does not apply to third-party vendors governed by separate Master Service Agreements that include their own security training obligations. In those cases the vendor contract controls.

3. Policy Statement

Completion of the required security training is a condition of ongoing access to company systems. Personnel who do not meet completion requirements within the windows defined below will have access reviewed and may have access revoked until training is complete.

4. Required Training

4.1 Initial Training

All personnel in scope must complete initial security training before they are granted production access or within [30] days of their start date, whichever comes first. No exceptions may be granted without written approval from the Policy Owner.

4.2 Annual Refresh

All personnel in scope must complete the annual security training within 12 months of their most recent completion. Completion dates are tracked per person.

4.3 Event-Driven Training

In addition to scheduled training, ad hoc training may be required:

• After a material change to this policy or the underlying curriculum.
• After a security incident that the Policy Owner determines is attributable in whole or part to a training gap.
• After a significant change to the product, infrastructure, or threat landscape.

Personnel have [14] days from notification to complete event-driven training.

4.4 Role-Based Training

Training is scoped by job function:

• All personnel: General Security Awareness, covering password hygiene, multi-factor authentication, phishing, data handling, incident reporting, social engineering, physical security, and acceptable use of AI tools.
• Engineering (software developers, site reliability, platform, security engineers): the above, plus OWASP Top 10 application security training covering access control, cryptographic failures, injection, insecure design, misconfiguration, supply chain, authentication failures, data integrity, logging, and exceptional-condition handling.
• Administrative and support personnel with access to customer data: the above general training, plus targeted modules on data classification and customer data handling.

Managers are responsible for ensuring their direct reports receive the role-appropriate curriculum.

5. Curriculum Requirements

5.1 Baseline Topics (all personnel)

The baseline curriculum must include, at minimum:

• Authentication and password security, including MFA.
• Phishing, pretexting, and social engineering recognition.
• Data classification and handling rules, aligned to the company Data Classification Policy.
• Acceptable use of email, messaging, file sharing, and AI tools.
• Physical security of company-issued devices and workspaces.
• Incident recognition and reporting procedures.
• Secure remote work and public network use.

5.2 Engineering Topics (software developers)

In addition to baseline topics, developers must cover:

• All ten categories of the current OWASP Top 10 for web applications.
• Secure coding practices for the company's primary languages and frameworks.
• Authentication, authorization, and session management, including token handling.
• Cryptographic controls: what to use, what to avoid, and how to store keys.
• Software supply chain risks, including dependency review, lockfile discipline, and typosquatting awareness.
• Logging and monitoring expectations for security-relevant events.

5.3 Role-Specific Additions

The Policy Owner may add required modules for roles that handle regulated data (PII, PHI, PCI), customer administrative tools, or privileged infrastructure access.

6. Completion Requirements

Training is considered complete for a given person and course when all of the following are met:

• Every required module for that course has been marked complete.
• Each module quiz has been passed with a score of [80]% or higher on a scored attempt within the current training cycle.
• The person has read and digitally signed the course attestation statement.

The training platform of record produces timestamped, tamper-evident records of quiz scores, module completion, and attestation signatures. These records are the authoritative evidence of completion.

Self-study and unscored viewing do not count as completion. Training completed more than 12 months prior does not count as current.

7. Frequency and Cadence

• New hires: initial training must be complete before production access or within [30] days, whichever first.
• Annual refresh: within 12 months of last completion.
• Policy or curriculum change: as directed by the Policy Owner, typically within [14] days.
• Post-incident: as directed by the Policy Owner, typically within [14] days.

The company tracks upcoming training deadlines and notifies personnel at [30], [14], and [7] days before each deadline.

8. Exceptions and Accommodations

8.1 Accommodations

Personnel who require accommodation to complete the training, including for disability or language-access reasons, should contact [Accommodations Contact]. Reasonable alternatives will be provided at no impact to the individual's standing.

8.2 Short Extensions

Short extensions of up to [30] days may be granted by the Policy Owner in cases of extended leave, urgent business needs, or comparable circumstances. Extensions are recorded with rationale and a new deadline.

8.3 Exemptions

Exemptions from the policy itself are rare and require written approval from the Policy Owner and the person responsible for the relevant system access. Approved exemptions are logged and reviewed annually.

9. Non-Compliance

Personnel who miss a training deadline are subject to the following escalation:

• Day 0 past deadline: automated reminder to the person and their manager.
• Day [7]: second reminder, with copy to the manager's manager.
• Day [14]: access to production systems and customer data is suspended until training is complete.
• Day [30] and beyond: referred to HR for progressive corrective action consistent with the company's performance and disciplinary policies.

Access suspension is procedural, not disciplinary on its own. Disciplinary action is governed by HR policy.

10. Roles and Responsibilities

• Policy Owner ([Policy Owner Title]): maintains this policy, approves exceptions, oversees curriculum review, and owns reporting to auditors and leadership.
• Training Administrator ([Training Administrator Title]): operates the training platform, manages campaigns, onboards new hires into training, and produces periodic compliance reports.
• Managers: responsible for ensuring their direct reports complete training within required windows. Receive escalation notices for overdue direct reports.
• All personnel in scope: responsible for completing required training on time, honestly attesting to completion, and reporting any content gaps or policy questions.
• Executive sponsor ([Executive Title]): annually approves this policy and the current curriculum.

11. Recordkeeping and Evidence

The company maintains the following records for a minimum of [7] years or for the period required by the strictest applicable regulation:

• Per-person completion records, including course, modules passed, quiz scores, completion date, and attestation signature.
• Campaign assignments and deadlines.
• Exception and extension approvals with rationale.
• Version history of this policy and the curriculum.

Records are produced in CSV or PDF form on request for internal reviews, customer due diligence, or external audits.

12. Policy Review

This policy is reviewed at least annually by the Policy Owner and updated as needed to reflect:

• Changes to applicable frameworks (SOC 2, ISO 27001, NIST, or sector-specific regulations).
• Changes to the company's products, infrastructure, or threat model.
• Observed gaps from incidents, audits, or internal reviews.

All material changes are approved in writing by the Executive Sponsor and communicated to all personnel in scope. Previous versions are retained per Section 11.

13. Related Documents

• Information Security Policy
• Acceptable Use Policy
• Data Classification Policy
• Incident Response Policy
• HR Performance and Disciplinary Policy
• Access Control Policy

14. Sign-off

Notes for adopting companies

These notes are guidance for the reader. They are not part of the policy itself. Delete this section before finalizing your company's adopted version.

Company size considerations

1 to 20 people: the Policy Owner, Training Administrator, and Executive Sponsor are often the same person (typically the CTO, head of engineering, or founder). Keep the policy as written; collapse the signatories to the single role.

20 to 200 people: designate a security champion or a head of IT to own the Training Administrator duties. The Policy Owner role often sits with the CTO or head of engineering; the Executive Sponsor is the CEO or CISO-equivalent.

Over 200: integrate this policy under a formal Information Security Management System (ISMS) if you operate one. The Policy Owner is typically the CISO; the Training Administrator role is a formal function, sometimes dedicated.

Numbers to confirm for your organization

The bracketed numbers in this template are starting points used by small and midsize SaaS companies. Adjust for your environment:

• Initial training within [30] days. More conservative organizations require completion before any system access (day 0). Some industries require fewer days by regulation.
• Passing score of [80]%. 70 to 80 is the most common range. Do not drop below 70.
• Record retention of [7] years. PCI requires 3, HIPAA requires 6, SOX requires 7. Choose the longest that applies to you.
• Escalation windows of [7], [14], [30] days past deadline. Tune to your culture and to how urgently your auditors expect access to be revoked.

Alignment notes

This template maps to:

• SOC 2 Trust Services Criteria CC1.4 (demonstration of commitment to a competent workforce) and CC2.2 (internal communication of internal-control information). Completion records and this signed policy are the primary evidence auditors sample.
• ISO/IEC 27001 Annex A.6.3 (Information security awareness, education, and training). A written policy, a defined curriculum, and retained completion records are the expected artifacts.
• NIST SP 800-50 (Building an Information Technology Security Awareness and Training Program). The framework is advisory rather than contractual, but most SOC 2 and ISO auditors recognize a program modeled on 800-50.

What this template deliberately does not include

• Course pricing and vendor selection: handled in your procurement policy.
• Phishing simulation program specifics: usually a separate operational playbook.
• Content creation responsibility: presumed to live with the training provider or with the Policy Owner for custom material.
• Board or committee oversight structure: add this for regulated industries.

This template is provided as-is by Top 10 Dev Training. It is not legal advice. Have your compliance counsel review any policy before adoption.