SnowBe Online Security Policy & Threat Modeling Portfolio

How each policy is structured

Every policy names the Chief Information Security Officer as owner, carries an effective date of May 3, 2026, sets an annual review with an event-based trigger, and states who it applies to. The body follows one pattern: purpose, scope, policy statement, requirements, roles and responsibilities, and compliance. Each purpose is grounded in SnowBe's actual environment, so the requirements read as answers to specific risks.

Secure SDLC policy: security in all nine phases

The policy statement is that security shall not be treated as an afterthought or only as a final review before implementation. The requirements are written phase by phase:

• Analysis: identify sensitive data, legal requirements, and risks. Systems that process customer information, purchase history, payment data, or employee records are classified as sensitive.
• Planning: each project includes security requirements, approvals, owners, and compliance obligations, with PCI requirements for PCI-related systems.
• Design: threat modeling for new systems, major updates, cloud architecture changes, and payment processing changes, identifying assets, data flows, trust boundaries, actors, threats, vulnerabilities, and mitigations.
• Development: no hardcoded credentials, insecure protocols, weak authentication, excessive permissions, poor input validation, or unsafe handling of customer data.
• Testing: vulnerability scanning, access control review, authentication testing, patch verification, and audit log validation. Systems that fail may not go to production until remediated or formally risk accepted.
• Deployment: secure configuration first, including firewall rules, access control, logging, encryption, backups, anti-virus, and approved patch levels.
• Maintenance: monitoring, patching, and backups, with login audit records retained for at least three months and then archived to approved cloud storage.
• Evaluation: periodic review of controls, user access, patch status, backup status, audit logs, and threat model updates.
• Disposal: secure decommissioning, with data retained or destroyed according to legal, business, and compliance requirements.

Patch management and maturity management policies

The patch policy starts from an accurate inventory of everything that needs patching, including network device firmware, WordPress components, VPN services, anti-virus, and backup software. Critical patches for actively exploited vulnerabilities, internet-facing systems, payment systems, remote access, or customer data systems are prioritized for rapid deployment, while medium and low-risk patches go out in scheduled maintenance windows. Patches are tested when practical, approved before deployment, and verified afterward, and failed patches are tracked until resolved. Emergency patches may move faster when the risk of delay is greater than the risk of implementation, and that decision must be documented. Unsupported or unpatched systems may be removed from the network.

The maturity policy requires the assessment to rate whether controls are ad hoc, documented, repeatable, managed, or optimized. The CISO sets maturity targets per domain, with higher priority for domains involving customer information, credit card data, AWS systems, remote access, audit logging, and access management. Every gap is recorded with a description, affected systems, risk level, required improvement, responsible owner, target date, and status. All three policies handle exceptions the same way: CISO approval, a business justification, compensating controls, and an expiration or review date.

Where threat modeling fits

• In the system development life cycle, threat modeling shows how interconnected systems interact, where sensitive information flows, and where trust boundaries exist, so concerns surface before they become expensive to fix.
• In the software development life cycle, the focus narrows to code, application logic, user input, authentication, authorization, and data handling. For the WordPress shopping cart that means risks such as insecure plugins, poor input validation, unpatched components, SQL injection, cross-site scripting, and session hijacking.
• In security maturity, threat modeling moves an organization from reactive to proactive, repeatable practice by giving it a structured method and documentation that can be reviewed as systems change.
• In the security plan and policies, it provides evidence-based direction. If the threat model shows excessive employee access to server data, that should shape the access management policy. If it shows the shopping cart exposed to internet-based threats, that should shape patch management. If it identifies missing logs, that should strengthen audit requirements.

The conclusion is that a security plan should not be a generic list of controls. Threat modeling keeps it practical by connecting policies to real risks, real systems, and real business needs.