Security Awareness and Training
Security is embedded in how the WiserReview team builds and operates the platform every day. This policy documents our onboarding, ongoing awareness, and secure coding requirements for all team members.
Version
1.0
Effective Date
March 2026
Owner
Security Team
1. Purpose and Scope
This policy establishes WiserReview's approach to security awareness and training. It ensures that all team members understand their security responsibilities, are equipped to recognize and respond to security threats, and follow secure practices in their daily work.
At 15 people, the most effective security training mechanism is a culture where security is considered in every code review, every deployment, and every tool decision, not a periodic checkbox exercise.
| Applies To | Scope |
|---|---|
| Full-time employees | All roles across engineering, product, and operations |
| Contractors and freelancers | Anyone with access to WiserReview systems, source code, or customer data |
| Any onboarded individual | Anyone interacting with infrastructure, code repositories, or internal tools |
2. Onboarding Security Checklist
Every new team member completes security onboarding before being granted access to production systems or customer data. The Engineering Lead is responsible for delivery; the Security Officer reviews the process annually.
Day 1: Security Policy Review
- Information Security Policy reviewed and signed
- Access Control Policy reviewed (least-privilege, access provisioning and de-provisioning)
- Acceptable Use Policy reviewed
- Data Privacy and Protection Assessment reviewed (what data we hold and how to handle it)
- Incident Response Plan reviewed: understand how to report a security concern
Day 1–3: System Access Provisioning (Least Privilege)
- GitHub organization access provisioned at appropriate scope
- MFA/2FA enabled on GitHub account (required before access is granted)
- Azure portal access provisioned at minimum required scope (if applicable)
- MFA enabled on Azure account (required if any Azure portal access)
- MongoDB Atlas access provisioned only if role requires it (Engineering Lead only for production)
- Slack workspace access provisioned
- Password manager usage encouraged for strong, unique credentials
Week 1: Developer Onboarding (Engineering Roles)
- Secure coding practices walkthrough with Engineering Lead (see Section 4)
- Codebase walkthrough: authentication patterns, client-scoped data access, secrets management, input validation
- CI/CD pipeline walkthrough: deployment process and security controls
- Code review process explained: security as part of review criteria
Week 1–2: Data Handling
- Data classification understood: Critical customer data, Confidential, Internal, Public
- GDPR awareness: data subject rights in practice; how automated data deletion works
- Customer data is never used for any purpose other than service delivery
- No customer data to be downloaded to personal devices or unsecured storage
3. Ongoing Security Awareness
Security awareness is maintained continuously through the team's engineering practice, not just through periodic training events.
Annual Security Review Session
Once per year, the Engineering Lead and Security Officer conduct a team-wide security awareness session. Attendance is required for all team members. The session is documented.
- •Review of the past year's security incidents (if any) and lessons learned
- •Review of any significant changes to the platform's security posture
- •Updates to security policies: team walkthrough of any material changes
- •Discussion of emerging threats relevant to SaaS platforms (phishing, supply chain attacks, API security)
- •Compliance roadmap progress review
Day-to-Day Security Awareness
| Mechanism | Description |
|---|---|
| Code reviews | Security is an explicit code review consideration. Reviewers check for: input validation, access control, credentials in code, injection vulnerabilities, and authentication correctness. |
| Slack security updates | Relevant security advisories, dependency vulnerability disclosures, and new threat intelligence are shared in team Slack when applicable. |
| Engineering discussions | Security considerations are raised during feature planning and architecture discussions, not just post-implementation. |
| Dependency awareness | The engineering team maintains awareness of third-party dependency health. Notable vulnerabilities (e.g., critical npm package CVEs) are flagged and patched promptly. |
4. Security Incident Reporting
All team members are responsible for reporting security concerns promptly. When in doubt, report it. A false alarm is always preferable to a delayed response to a real issue.
Suspected vulnerability or security issue
Report to Engineering Lead immediately via Slack DM or the #security channel.
Suspected credential compromise
Report to Engineering Lead and Security Officer immediately. Credential rotation begins within the hour.
Policy violation (self or observed)
Report to Security Officer. No retaliation for good-faith reports.
5. Secure Coding Practices
These practices apply to all engineers working on WiserReview services. They are enforced through code reviews and are part of the standard engineering workflow.
Input Validation
- Validate all user input at the API boundary. Never trust client-supplied data.
- MongoDB document IDs from user input must be validated as valid ObjectIDs
- File uploads validated for MIME type, size limits, and content type
- Webhook payloads validated via HMAC signature verification before processing
- Never pass unsanitized user input into database queries, shell commands, or templates
Authentication and Authorization
- Every API endpoint operating on customer data must verify JWT token authentication
- Every database query on customer data must include the unique client identifier as a filter
- Bulk operations must include the client identifier alongside any ID-based filters
- Never bypass authentication middleware during development: use staging tokens instead
- OAuth token storage: tokens stored encrypted; platform passwords never stored
Credentials and Secrets
- Zero tolerance for credentials in source code: no API keys, passwords, JWT secrets, or tokens
- All secrets stored in GitHub encrypted secrets vault; injected as environment variables at runtime
- If a credential is accidentally committed, it is considered compromised and must be rotated immediately
- Local development uses separate, non-production credentials only
Dependency Management
- Third-party packages pinned to specific versions in package.json and package-lock.json
- Docker base images pinned to specific versions, not latest tags
- New dependencies require a brief justification in the PR
- Actively maintained packages preferred; unmaintained packages with known vulnerabilities must be replaced
- Regularly review npm audit output and address high/critical vulnerabilities promptly
Error Handling and Logging
- Application errors must be caught and handled; unhandled promise rejections are a code review failure
- Error messages returned to the client must not reveal stack traces, internal paths, or implementation details
- Logging must never include passwords, JWT tokens, OAuth tokens, customer PII, or payment information
- Sentry error tracking captures errors automatically; do not duplicate PII in additional logs
Output Encoding
- User-generated content displayed in the dashboard or widget must be properly encoded to prevent XSS
- The React dashboard inherits React's built-in XSS protections
- Do not use dangerouslySetInnerHTML without explicit review
- API responses containing user data should set appropriate Content-Type headers
Code Review Security Checklist
Reviewers check the following for every pull request:
- No credentials or secrets in the diff
- All new API endpoints have authentication middleware applied
- Database queries on customer data include client identifier scoping
- User input is validated before use
- No new dangerouslySetInnerHTML or equivalent unsafe patterns
- New dependencies are justified and from reputable sources
- Error messages don't leak internal state
6. Policy Acknowledgment
| When | Requirement |
|---|---|
| On joining | New team members review and sign the security policy acknowledgment before gaining access to any production systems |
| Annually | All team members re-acknowledge policies each year, particularly following any material policy update |
| On material policy changes | Team members are notified and must acknowledge significant policy changes within 2 weeks |
Policy acknowledgment records are maintained by the Engineering Lead and reviewed by the Security Officer.
7. Consequences of Non-Compliance
Failure to comply with security policies is handled proportionate to the severity of the violation. The goal is not punitive: security errors should be caught early, corrected quickly, and learned from.
| Violation | Response |
|---|---|
| Accidental policy violation (e.g., committed a credential, skipped a code review) | Immediate remediation (credential rotation, retroactive code review); documented; coaching |
| Repeated accidental violations | Formal discussion with Security Officer; additional training; documented |
| Deliberate policy violation (e.g., bypassing authentication, accessing unauthorized data) | Immediate investigation; potential suspension of access; may result in termination and/or legal action depending on severity |
| Data breach or security incident caused by negligence | Full incident response process; disciplinary action based on severity; potential legal obligations |
8. Training Records
Records are retained for a minimum of 3 years to support audit and compliance activities.
| Record | Location | Maintained By |
|---|---|---|
| Onboarding security checklist (signed) | Internal HR/onboarding documentation | Engineering Lead |
| Annual security session attendance | Internal documentation (Slack/Notion/Google Docs) | Security Officer |
| Policy acknowledgment records | Internal documentation | Engineering Lead |
| Security incident records | Post-incident reports | Engineering Lead / Security Officer |
9. Formalization Roadmap
WiserReview's security training program will grow with the team.
| Timeline | Planned Improvement |
|---|---|
| 2026 (Ongoing) | Maintain and improve the code review security checklist; share relevant security advisories proactively |
| 2027 (SOC 2 preparation) | Introduce formal security training platform with documented completion tracking; role-specific modules for engineers vs. non-technical staff |
| 2027 | Phishing simulation exercises to test and improve team awareness |
| 2027–2028 (ISO 27001 preparation) | Formal security certification requirements for relevant team members; documented competency records |
| As team scales | CISO or dedicated Security Engineer role; MDM for device management; formal security onboarding program |