Cybersecurity Pre-Assessment Template – Free Word Download

Introduction

In the lifecycle of any technical project, security is often treated as a final hurdle to clear just before launch. This approach, often referred to as “bolting on” security, is fraught with risk. It leads to delayed timelines, expensive code refactoring, and, in worst-case scenarios, vulnerabilities making their way into production environments. The Cybersecurity Pre-Assessment is a project management and governance tool designed to shift security “left,” meaning it moves security considerations to the very beginning of the project lifecycle.

This document serves as an initial health check. It is not a penetration test or a full code audit. Instead, it is a strategic questionnaire intended to capture the security posture of a proposed solution while it is still in the design or planning phase. By completing this assessment, Project Managers, Solution Architects, and Security Leads can identify high-risk areas that require specialized attention, budget allocation, or architectural changes.

The primary goal of this template is to ensure that “Security by Design” principles are applied. It forces the project team to articulate how they plan to protect the confidentiality, integrity, and availability of the system. Whether you are deploying a new internal tool, launching a customer-facing mobile app, or migrating servers to the cloud, this assessment acts as the first line of defense. It ensures that security requirements are defined alongside functional requirements, rather than as an afterthought.

Please complete this document with the assistance of the technical lead or solution architect. Honesty is critical here; identifying a gap now costs nothing, whereas finding a gap after a data breach costs everything.

Section 1: Project Profile and Asset Definition

1.1 Project Context

Instructions:

This section contextualizes the assessment. It links the security review to specific project identifiers and timelines. This is vital for the security team to prioritize their queue. A project launching next week has a different urgency profile than one launching next year.

• Project Name: [Enter official name]
• Project ID: [Enter reference code]
• Project Sponsor: [Executive owner]
• Technical Lead/Architect: [Person responsible for the design]
• Target Launch Date: [Date]
• Environment: [e.g., Development, Staging, Production]

Guidance:

Ensure the Technical Lead listed is someone who understands the “nuts and bolts” of the system. This form asks technical questions that a generalist Project Manager might not be able to answer accurately.

1.2 Asset Identification

Instructions:

Security protects “assets.” An asset is anything of value to the organization. In this section, list the primary components being built, bought, or modified.

Table: Asset Inventory

Asset Name	Description	Type	Ownership
Example: Customer Database	SQL database storing user profiles	Data Store	IT Ops
Example: iOS App	Mobile interface for customers	Application	Product Team
[Insert Asset]	[Describe function]	[e.g., Server, API, Laptop, Codebase]	[Dept/Team]
[Insert Asset]	[Describe function]	[e.g., Server, API, Laptop, Codebase]	[Dept/Team]

Tips for Success:

Be granular. Do not just say “The System.” Break it down into “The Web Front-End,” “The API Layer,” and “The Backend Database.” Each of these has different security profiles and attack vectors.

1.3 Data Sensitivity Level

Instructions:

Referencing your Data Privacy Impact Screening (if completed), classify the data this system will handle. Security controls must match the data sensitivity.

• [ ] Public: Data intended for public consumption (e.g., marketing website).
• [ ] Internal Only: Business data not for public release (e.g., employee directory).
• [ ] Confidential: Sensitive business data (e.g., financial forecasts, trade secrets).
• [ ] Restricted/High Value: Critical data requiring highest protection (e.g., customer passwords, PII, credit card numbers).

Why is this important?

If you mark “Restricted,” the security team will immediately require higher standards, such as Multi-Factor Authentication (MFA) and advanced encryption. If you mark “Public,” the controls might be more relaxed regarding access, but stricter regarding availability (DDoS protection).

Section 2: Architecture and Infrastructure

2.1 Deployment Model

Instructions:

Where will this solution live? The physical or virtual location of the infrastructure dictates who is responsible for security.

• [ ] On-Premise: Hosted in our physical data centers.
• [ ] IaaS (Infrastructure as a Service): Hosted on cloud (AWS/Azure/GCP) but we manage the OS and Apps.
• [ ] PaaS (Platform as a Service): We manage only the Application and Data.
• [ ] SaaS (Software as a Service): Vendor manages everything; we just use it.
• [ ] Hybrid: A mix of the above.

Guidance for 2.1:

• Shared Responsibility Model: If you choose Cloud (IaaS/PaaS/SaaS), remember that the cloud provider is responsible for the security of the cloud (physical hardware), but you are responsible for security in the cloud (data, accounts, configurations).

2.2 Network Exposure

Instructions:

How can people or other systems reach this project? This defines the “Attack Surface.”

• Internet Facing: [Yes/No] (Can anyone on the web see it?)
• Intranet Only: [Yes/No] (Accessible only via VPN or office network?)
• Third-Party Connected: [Yes/No] (Does it connect to vendor networks?)

Risk Analysis Tip:

If the system is “Internet Facing,” it is immediately a target for bots and scanners. You must plan for Web Application Firewalls (WAF) and DDoS protection. If it is “Intranet Only,” the risk is lower but not zero, as insider threats or lateral movement from compromised endpoints are still risks.

2.3 Encryption Standards

Instructions:

Describe how data is protected from eavesdropping and theft.

• Data in Transit: [How is data protected while moving? e.g., TLS 1.2+, HTTPS, SFTP, VPN tunnel]
• Data at Rest: [How is data protected on the disk? e.g., AES-256, BitLocker, TDE]
• Key Management: [Who holds the keys? e.g., AWS KMS, Azure Key Vault, Hardware Security Module (HSM)]

Common Pitfalls:

Do not simply write “Encrypted.” Specify the protocol. “HTTP” is not encrypted; “HTTPS” is. Using old protocols like SSL v3 or TLS 1.0 is a security vulnerability. Ensure you are using current industry standards (currently TLS 1.2 or 1.3).

Section 3: Identity and Access Management (IAM)

3.1 Authentication Strategy

Instructions:

How do we know the user is who they say they are?

• User Type: [e.g., Employees, Customers, Partners]
• Authentication Method: [e.g., Username/Password, Single Sign-On (SSO), Biometrics, Magic Links]
• Identity Provider (IdP): [e.g., Active Directory, Okta, Google Auth, Custom Database]

Guidance:

Avoid building your own authentication database if possible. Storing passwords is difficult and risky. It is almost always better to federate identity using an established provider like Okta or Microsoft Azure AD via SAML or OIDC protocols.

3.2 Multi-Factor Authentication (MFA)

Instructions:

Is MFA required? If so, for whom?

• Administrators: [Mandatory / Optional / Not Available]
• General Users: [Mandatory / Optional / Not Available]
• MFA Type: [e.g., SMS, Authenticator App, Hardware Key (YubiKey)]

Policy Note:

For any system accessible over the internet or hosting “Restricted” data, MFA should be mandatory for all administrative accounts. SMS-based MFA is better than nothing, but app-based or hardware-based MFA is significantly more secure against SIM-swapping attacks.

3.3 Authorization and Role-Based Access Control (RBAC)

Instructions:

Once a user is logged in, what can they do? Describe the permissions model.

• Least Privilege Principle: describe how you ensure users only have the access necessary to do their jobs.
• Role Definitions: List the high-level roles (e.g., Admin, Editor, Viewer).
• Review Process: How often will access rights be audited?

Example:

“The system uses three roles: ‘Viewer’ (Read-only), ‘Editor’ (Can modify data but not delete), and ‘Admin’ (Full control). We review Admin access quarterly to ensure no termed employees retain access.”

Section 4: Application Security and Development

4.1 Secure Development Lifecycle (SDLC)

Instructions:

If this project involves writing custom code, how are you ensuring the code is secure?

• Source Code Management: [Where is code stored? e.g., GitHub, GitLab, Bitbucket]
• Peer Review: [Are code reviews mandatory before merging?]
• Static Analysis (SAST): [Do you use tools to scan code for bugs automatically? e.g., SonarQube, Veracode]
• Dynamic Analysis (DAST): [Do you scan the running application for vulnerabilities?]

Guidance:

If you are using external code repositories like GitHub, ensure that the repository is “Private” unless it is an open-source project. A common error is accidentally leaving a repository public, exposing proprietary code and hard-coded passwords to the world.

4.2 Dependency Management

Instructions:

Modern software is built on libraries and frameworks (e.g., React, Spring, Django). These third-party components often contain vulnerabilities.

• Inventory: Do you have a list of all third-party libraries used? [Yes/No]
• Scanning: Do you use a tool to check for “Known Vulnerabilities” in these libraries? (e.g., Snyk, OWASP Dependency Check) [Yes/No]

Why is this important?

The “Log4j” vulnerability is a classic example. A small, obscure logging library used by millions of applications had a flaw that allowed hackers to take over servers. If you do not know what libraries you are using, you cannot patch them when a vulnerability is discovered.

4.3 Input Validation and Sanitization

Instructions:

How does the application handle data input from users? Improper validation leads to attacks like SQL Injection (SQLi) and Cross-Site Scripting (XSS).

• Strategy: [Describe how inputs are checked. e.g., “All inputs are validated against a whitelist of allowed characters.”]
• Framework Protections: [Does your development framework handle this automatically?]

Tips for Success:

Never trust user input. Assume every piece of data coming from a browser or API client is malicious until proven otherwise. Use parameterized queries for all database interactions to prevent SQL injection.

Section 5: Logging, Monitoring, and Incident Response

5.1 Audit Trails

Instructions:

If a breach occurs, you need to know what happened. Logging provides the evidence.

• What is logged? [e.g., Successful logins, Failed login attempts, Data deletion, Privilege changes]
• Where are logs stored? [e.g., Local disk, Centralized Syslog server, SIEM (Splunk/Datadog)]
• Retention: [How long are logs kept? e.g., 30 days, 1 year]

Guidance:

Logs must be stored separately from the system generating them. If a hacker compromises a server, the first thing they will do is delete the local logs to cover their tracks. Shipping logs to a centralized, write-only location preserves the evidence.

5.2 Monitoring and Alerting

Instructions:

Who is watching the logs?

• Real-Time Alerting: [Are there alerts for suspicious activities? e.g., 5 failed logins in 1 minute]
• Responsibility: [Who receives the alert? e.g., The NOC, The Security Team, The On-Call Developer]

5.3 Incident Response Integration

Instructions:

Does this project have a specific plan for when things go wrong?

• Runbook: Is there a specific guide for restoring this system after an attack? [Yes/No]
• Contact Point: In an emergency, who is the primary technical contact? [Name/Phone]

Example:

“In the event of a suspected breach, the team will follow the Corporate Incident Response Plan (IRP-2024). The primary contact is John Doe (DevOps Lead), and the secondary is Jane Smith (Engineering Manager).”

Section 6: Third-Party and Supply Chain Risk

6.1 Vendor Access

Instructions:

If this project involves a vendor, do they have access to our systems?

• Connection Type: [VPN, Remote Desktop, API Integration]
• Monitoring: [Do we monitor what the vendor does while connected?]
• Termination: [Is there a process to remove vendor access immediately when the contract ends?]

6.2 Data Sharing Agreement

Instructions:

If data is sent to a third party, is there a contract enforcing security standards?

• Agreement Status: [Signed, In Review, Not Started]
• Right to Audit: [Do we have the legal right to test the vendor’s security?]

Risk Note:

Vendors are often the “weakest link.” A hacker might not be able to breach your fortress, but they might breach your HVAC vendor who has a remote connection to your network. Ensure vendors are held to the same security standards as internal employees.

Section 7: Regulatory and Compliance Requirements

Instructions:

Certain industries have strict security laws. Check all that apply to this project.

• [ ] PCI-DSS: Processing credit card payments. (Requires strict network segmentation and encryption).
• [ ] HIPAA: Processing US healthcare data. (Requires strict access controls and audit logs).
• [ ] SOC 2: Service Organization Control. (Requires rigorous documentation of controls).
• [ ] ISO 27001: International security standard.
• [ ] GDPR/CCPA: Privacy regulations with security mandates (e.g., “Right to be Forgotten”).

Guidance:

If you check any of these boxes, the project likely requires a formal compliance review. Do not proceed without consulting the Compliance Officer. Failure to adhere to PCI-DSS, for example, can result in the company losing the ability to process credit card payments entirely.

Section 8: Assessment Findings and Risk Scoring

Instructions:

Based on the answers in the previous sections, the Security Team or Project Manager summarizes the findings here.

8.1 Identified Gaps

Format: [Area of Concern] + [Description of Gap] + [Risk Level: High/Medium/Low]

Examples:

• Gap: “The web application allows users to upload files, but there is no malware scanning on the upload bucket.” -> Risk: High. (Potential for distributing malware).
• Gap: “Admin console is accessible via the public internet without a VPN.” -> Risk: Medium. (Increased attack surface).
• Gap: “Logs are only retained for 24 hours due to storage costs.” -> Risk: Medium. (Insufficient for forensic investigation).

8.2 Required Remediations

Instructions:

List the “Must-Haves” before the project can go live.

1. Remediation: [e.g., Implement antivirus scanning for file uploads] | Owner: [Dev Team]
2. Remediation: [e.g., Restrict Admin console access to office IP range] | Owner: [NetOps]
3. Remediation: [e.g., Increase log retention to 90 days] | Owner: [DevOps]

Conclusion – Cybersecurity Pre-Assessment Template – Free Word Download

The Cybersecurity Pre-Assessment is the bridge between functionality and safety. By completing this document, the project team has demonstrated a commitment to due diligence. It is important to remember that security is not a “one-and-done” activity. The answers provided here represent the system as it is currently designed. If the design changes for instance, if you decide to switch from a private internal server to a public cloud bucket the risk profile changes, and this assessment must be revisited.

This document should be stored in the project’s permanent governance repository. It serves as proof that the organization considered security risks before deployment. For the Project Manager, this document is an insurance policy; it confirms that you engaged the security experts early and followed their guidance.

Final Approval Decision:

• [ ] Approved for Development: Security risks are managed or accepted.
• [ ] Conditional Approval: Approved subject to the completion of “Required Remediations” listed in Section 8.2.
• [ ] Rejected/On Hold: Critical security flaws exist. Architecture must be revised.

Signatures:

• Project Manager: ___________________ Date: __________
• Security Architect: ___________________ Date: __________
• Technical Lead: ___________________ Date: __________

---

Meta Description:

A detailed Cybersecurity Pre-Assessment template to evaluate project security posture, identify risks in architecture and data handling, and ensure compliance before development.

Discover More great insights at www.pmresourcehub.com