Information security awareness training¶

Classification: Internal — training record supported
Document: Cloudnaut Technologies — Security awareness module
Version: 1.0
Effective: 2026-05-13
Aligned with: Information Security Training Policy
Estimated duration: 45–60 minutes (self-paced or facilitated)

This module satisfies the annual information security awareness requirement for personnel who access company or customer systems, repositories, data, or credentials. Retain this document (or controlled PDF export), version identifier, and attendance list per the training policy.

Learning objectives¶

After completing this module, you should be able to:

Recognize common phishing and social-engineering tactics and respond safely.
Apply sound password and multi-factor authentication (MFA) practices.
Handle customer and company confidential information according to need-to-know and least privilege.
Use source repositories, branches, and reviews without exposing secrets or customer data.
Meet baseline expectations for endpoints used for customer work (encryption, patching, malware protection, firewall).
Know when and how to report a suspected security incident.
Respect customer access boundaries and engagement separation.

1. Introduction¶

1.1 Why this matters¶

Cloudnaut delivers engineering and consulting services where mistakes can affect customer trust, contracts, and regulatory expectations. Security awareness is part of professional delivery—not only an IT task.

1.2 Who must complete training¶

Everyone who may access company or customer systems, repositories, data, or credentials—including employees, contractors, and subcontractors in engineering, QA, leadership, and operations support.

1.3 Your responsibilities¶

Follow applicable policies and customer contractual requirements when they are stricter than general guidance here.
Ask when instructions are unclear, especially for data access, credentials, or customer environments.
Report suspected incidents or policy violations without delay (see section 8).

2.1 What attackers want¶

They often want credentials, access to email or chat, code or customer data, or execution of a fraudulent payment. Many attacks start with a message that creates urgency, fear, or curiosity.

2.2 Red flags¶

Unexpected links or attachments, especially invoices, “security alerts,” or HR forms you did not request.
Sender display name that does not match the real domain; slight misspellings of known domains.
Requests to bypass normal process: “Send the customer database to this personal email,” “Disable MFA just for today,” “Use this unknown USB.”
Pressure to act now without verification.

2.3 What to do¶

Do not click links or open attachments when in doubt. Verify through a second channel (known phone number, internal ticket, or manager).
Do not enter credentials on a page you reached from an unsolicited link.
Report suspicious messages according to internal procedure (security contact, IT, or management).

3. Passwords and multi-factor authentication (MFA)¶

3.1 Passwords¶

Use long, unique passwords or passphrases for work accounts. Avoid reuse across personal and work systems.
Prefer a company-approved password manager where available.
Never share passwords or “team passwords.” Shared accounts are a last resort and must be approved and logged.

3.2 MFA¶

Enable MFA on all services that support it (email, Git hosting, cloud consoles, VPN).
Protect MFA factors: do not approve random push prompts; treat backup codes like passwords.
Lost device used for MFA: report immediately.

3.3 Session and lock screen¶

Lock your screen when stepping away (session lock is required on customer-work endpoints per endpoint policy).
Do not store session tokens in screenshots or public channels.

4. Data handling and confidentiality¶

4.1 Types of information¶

Treat the following as sensitive unless explicitly marked otherwise or approved for wider distribution:

Customer business, technical, and security information.
Personal data (names, contact details, identifiers) and any regulated categories your engagement touches (health, financial, etc.)—only when authorized and in scope.
Credentials, keys, tokens, connection strings, and internal roadmaps or financial data.

4.2 Rules of thumb¶

Need to know: access only what your role and engagement require.
Customer-approved systems: store and transfer customer-related data using paths the customer or engagement lead approves.
No “shadow copies” on personal drives, personal email, or unapproved cloud storage.
No posting customer code, logs with customer data, or credentials in public forums, chat channels, or social media.

4.3 Regulated or high-risk data¶

If your work might involve regulated or highly sensitive data outside the agreed scope, stop and escalate to your lead and, where required, the customer before proceeding.

5. Source control, secrets, and safe collaboration¶

5.1 Repositories and branches¶

Work in engagement-specific or customer-approved repositories and branches.
Use pull requests (or equivalent) and peer review before merging changes that affect customer systems or deliverables.

5.2 Secrets and credentials¶

Never commit secrets, API keys, passwords, or customer production data to Git.
Use customer-approved secret stores, CI variables, or vault mechanisms.
Rotate credentials if you suspect exposure.

5.3 Dependencies and supply chain¶

Be aware of dependency and container risks; follow team process for updates and scanning (for example Dependabot, Snyk) where used on the engagement.

6. Endpoint and device security¶

Expectations align with the Endpoint Security Policy and Patch Management Policy for devices used for customer work:

Full disk encryption: Linux (LUKS); Windows QA systems (BitLocker or approved equivalent) before customer access.
Anti-malware: ESET (or as directed) with automatic updates where supported.
Firewall: host firewall enabled.
Patching: apply OS updates on at least a monthly cadence; treat critical security patches with priority (seven-day target where feasible).
Tools: keep IDEs and plugins updated; disable telemetry where required; use only engagement-authorized repositories and accounts.

If your device cannot meet these requirements, do not use it for customer work until remediated or an approved exception is documented.

7. Physical and office security¶

Tailgating: do not hold secure doors open for unknown persons without verification.
Clean desk: sensitive printouts and hardware tokens secured when unattended.
Removable media: only use approved USB or storage; do not use unknown devices on work machines.

8. Incidents and reporting¶

8.1 What counts as an incident¶

Examples include: suspected phishing success, lost or stolen laptop or phone used for work, accidental customer data exposure, ransomware or malware alert, credential leak, unauthorized access attempt, or service outage caused by a security event.

8.2 What to do¶

Contain if safe to do so (for example: disconnect from network only if instructed or if clearly necessary to stop spread—when unsure, ask).
Report immediately to your manager and security/IT contact. Include what happened, when, and what systems or data may be involved.
Preserve evidence where practical (do not delete logs or messages unless directed).
Cooperate with investigation and remediation.

9. Customer access and engagement boundaries¶

Use only accounts, VPNs, repositories, and permissions approved for the specific engagement.
Do not reuse access from a different contract or a direct customer relationship when working under a prime contractor or separate engagement unless written approval says you may.
When in doubt about role boundaries (for example who may approve security sign-off for the customer or prime), escalate before acting.

10. Knowledge check (self-review)¶

Answer mentally or on paper; discuss wrong answers with your lead.

Phishing: You receive an urgent email from “IT” with a link to “re-validate your password.” Best first step?
A) Click and reset quickly B) Verify via a known internal channel before acting C) Forward to everyone
Expected: B.
MFA: You get a push notification you did not trigger. You should:
A) Approve once to clear it B) Deny and report C) Ignore forever
Expected: B.
Secrets: A teammate asks you to paste a production API key in Slack “just for a minute.” You should:
A) Use an approved secret mechanism instead B) Paste in a private DM only C) Email it
Expected: A.
Data: Customer data may be copied to your personal laptop if:
A) The file is small B) Never, unless explicitly approved by customer and company policy C) Only over the weekend
Expected: B.
Repos: Default branch protection and peer review are important because they:
A) Slow down attackers B) Reduce risk of unreviewed or malicious changes C) Are optional for internal tools only
Expected: B.
Endpoints: Customer work on a Windows laptop without disk encryption is:
A) OK if fast B) Not permitted until BitLocker or approved equivalent is enabled C) Only a customer problem
Expected: B.
Patching: Critical OS security patches should be:
A) Ignored until yearly B) Prioritized; seven-day target where feasible per policy C) Applied only if the machine feels slow
Expected: B.
Incident: You accidentally sent a spreadsheet with customer emails to the wrong external address. You should:
A) Recall silently B) Report immediately per incident procedure C) Delete your copy only
Expected: B.
Access: You still have VPN access from an old project with the same customer but a new engagement forbids using it. You should:
A) Use it to save time B) Not use it; request proper access or written approval C) Share VPN with a colleague
Expected: B.
Reporting: The primary reason to report near-misses (not only successful breaches) is:
A) To improve defenses and meet obligations B) Optional C) Only if the customer asks
Expected: A.

11. Completion and attestation¶

By completing this module (self-paced read-through, live session, or recording plus this document), you confirm that you:

Have reviewed the material in version 1.0 (or the version shown on your attendance record).
Understand where to find current policies (for example the IT / ITSEC policy repository).
Will follow escalation and incident reporting expectations.

Training completion record (print or duplicate for HR / security file)

Field	Value
Participant name
Role / team
Date completed
Material version	1.0 (2026-05-13)
Delivery method	☐ Self-paced ☐ Live session ☐ Recording + Q&A
Signature (if paper / PDF)

Approver (optional for facilitated sessions)

Field	Value
Facilitator / manager name
Date
Signature

12. References (Cloudnaut policy library)¶

End of module. Retain this document with your training records.