1. Purpose
The Project Risk Assessment Template is used to identify, analyse, evaluate, and treat information security risks introduced or affected by a project.
The assessment helps the project team determine:
- What information and assets are involved.
- What could go wrong.
- How a threat could affect the project.
- What vulnerabilities or weaknesses may exist.
- What security controls are already in place.
- What additional treatment is required.
- Who owns each risk.
- What residual risk remains after treatment.
The assessment should be proportionate to the project’s size, complexity, technology, data, and business impact.
2. Project Information
| Field | Details |
|---|---|
| Project Name | [Project Name] |
| Project ID | [Project ID] |
| Project Manager | [Name] |
| Business Owner | [Name] |
| Security/Risk Owner | [Name] |
| Technical Owner | [Name] |
| Assessment ID | PRA-XXXX |
| Assessment Date | [Date] |
| Assessment Period | [Period] |
| Project Phase | [Planning / Design / Development / Testing / Deployment] |
| Assessment Scope | [Systems / Applications / Data / Infrastructure] |
| Methodology | [Organization’s Risk Methodology] |
| Assessor | [Name] |
| Approver | [Name] |
| Next Review | [Date] |
3. Assessment Scope
Define what is included in the project risk assessment.
Example
Project: New SaaS Application
Scope:
- AWS production environment
- Application
- APIs
- Customer database
- Source code
- CI/CD pipeline
- Developer access
- Third-party integrations
- Customer information
Out of Scope
Document anything intentionally excluded and the reason.
| Item | Scope | Reason |
|---|---|---|
| AWS Production | In Scope | Core project environment |
| Customer Database | In Scope | Processes customer data |
| Corporate HR System | Out of Scope | Not affected by project |
4. Risk Assessment Methodology
The organization should use its approved information security risk assessment methodology.
A practical project-level model can follow:
Asset / Information → Threat → Vulnerability → Risk Event → Impact → Likelihood → Risk Level → Treatment
For example:
A compromised developer credential could provide unauthorized access to the production AWS environment, potentially resulting in unauthorized changes or customer data exposure.
5. Risk Scoring
If the organization uses a 5×5 scoring model, the following can be used as an example.
Likelihood
| Score | Level | Description |
|---|---|---|
| 1 | Rare | Very unlikely to occur |
| 2 | Unlikely | Could occur but not expected |
| 3 | Possible | Could reasonably occur |
| 4 | Likely | Expected to occur under certain conditions |
| 5 | Almost Certain | Very likely or frequent |
Impact
| Score | Level | Description |
|---|---|---|
| 1 | Insignificant | Minimal business/security impact |
| 2 | Minor | Limited impact |
| 3 | Moderate | Noticeable operational/security impact |
| 4 | Major | Significant business/security impact |
| 5 | Severe | Serious or potentially critical impact |
Risk Score
Risk Score = Likelihood × Impact
Example bands:
| Score | Risk Level |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–15 | High |
| 16–25 | Critical |
These scoring bands are an example methodology, not a universal ISO 27001 requirement. The organization’s approved risk methodology should take precedence.
6. Project Risk Register
| Risk ID | Asset / Information | Threat | Vulnerability / Weakness | Risk Event | Existing Controls | L | I | Initial Risk | Treatment | Risk Owner | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PR-001 | AWS Production | Credential compromise | Excessive privileges | Unauthorized production access | MFA, IAM | 4 | 5 | Critical | Reduce | Cloud Lead | Open |
| PR-002 | Customer Database | Unauthorized access | Weak access restrictions | Customer data exposure | Encryption, IAM | 3 | 5 | High | Reduce | Data Owner | Open |
| PR-003 | Application | Vulnerability exploitation | Vulnerable dependency | Application compromise | SAST, scanning | 4 | 5 | Critical | Reduce | Engineering | Open |
| PR-004 | CI/CD Pipeline | Credential theft | Insecure secret storage | Unauthorized deployment | Secret management | 3 | 4 | High | Reduce | DevOps | Open |
| PR-005 | Third-Party API | Supplier compromise | External dependency | Service/data exposure | Supplier assessment | 3 | 4 | High | Reduce/Share | Vendor Owner | Open |
7. Risk Identification
Risks should be specific to the project rather than copied from a generic risk list.
Weak Example
AWS security risk.
Better Example
A compromised privileged AWS credential could allow an unauthorized individual to modify production resources, potentially resulting in service disruption or unauthorized access to customer information.
A useful risk statement normally identifies:
Threat → Weakness → Risk Event → Consequence
8. Assets and Information
Identify assets that could be affected.
Examples:
- Customer data
- Personal data
- Source code
- Production systems
- Databases
- Cloud accounts
- APIs
- Credentials
- Encryption keys
- CI/CD pipelines
- Endpoints
- Third-party services
- Business processes
- Security logs
| Asset ID | Asset | Owner | Classification | Criticality |
|---|---|---|---|---|
| A-001 | Customer Database | Data Owner | Confidential | Critical |
| A-002 | AWS Production | Cloud Lead | Restricted | Critical |
| A-003 | Source Code | Engineering | Confidential | High |
| A-004 | CI/CD Pipeline | DevOps | Confidential | High |
9. Threat Identification
Consider threats relevant to the project.
Examples:
- Unauthorized access
- Credential compromise
- Malware
- Ransomware
- Phishing
- Insider misuse
- Application attack
- API attack
- Vulnerability exploitation
- Cloud misconfiguration
- Data leakage
- Supplier compromise
- Service outage
- Denial of service
- Accidental deletion
- Unauthorized change
- Physical loss
- Social engineering
Threats should be supported by the project’s actual environment and available evidence where appropriate.
10. Vulnerability / Weakness Identification
Identify conditions that could allow a threat to succeed.
Examples:
- Excessive privileges
- Missing MFA
- Weak authentication
- Unpatched software
- Vulnerable dependencies
- Public cloud exposure
- Insecure API
- Poor configuration
- Lack of monitoring
- Insufficient backup
- Inadequate access review
- Weak supplier controls
- Lack of security testing
11. Risk Event
Describe what could actually happen.
Examples:
An attacker obtains a privileged AWS credential and accesses production resources.
A vulnerable third-party library is exploited through the internet-facing application.
A CI/CD secret is exposed and used to deploy unauthorized code.
Avoid vague descriptions such as:
“Cybersecurity issue.”
12. Impact Assessment
Consider the potential effect on:
Confidentiality
Could information be disclosed to unauthorized parties?
Integrity
Could information or systems be modified without authorization?
Availability
Could systems or services become unavailable?
Privacy
Could personal or sensitive information be affected?
Business Operations
Could the project or organization experience:
- Service disruption
- Financial loss
- Customer impact
- Contractual consequences
- Regulatory consequences
- Reputation impact
The organization should use its approved impact criteria.
13. Likelihood Assessment
Consider factors such as:
- Exposure
- Threat activity
- Vulnerability
- Exploit availability
- Existing controls
- Attack complexity
- Access requirements
- Asset accessibility
- Previous incidents
- Threat intelligence
Document the reasoning rather than assigning a number without explanation.
Example
Likelihood: 4 – Likely
Reason:
The application is internet-facing and the affected component has known exploitation activity. Existing security controls reduce the likelihood but do not eliminate the exposure.
14. Initial Risk
Calculate the risk before considering additional treatment.
Example
Likelihood = 4
Impact = 5
Initial Risk = 4 × 5 = 20
Risk Level = Critical
The initial risk represents the risk before the additional project treatment is completed.
15. Existing Controls
Document controls that already reduce the risk.
Examples:
- MFA
- IAM
- Least privilege
- Encryption
- Firewalls
- WAF
- Vulnerability scanning
- Secure coding
- Code review
- Logging
- Monitoring
- Backup
- Security awareness
- Supplier assessment
- Incident response
- Change management
Do not list a control merely because a policy exists. Consider whether the control is actually implemented and operating.
16. Risk Treatment
Select an appropriate treatment option.
Reduce
Implement or strengthen controls to reduce likelihood and/or impact.
Avoid
Change or remove the project activity creating unacceptable risk.
Share / Transfer
Transfer or share part of the risk through contracts, insurance, suppliers, or other arrangements where appropriate.
Accept
Retain the risk based on the organization’s approved risk acceptance criteria and authorization process.
Risk acceptance should be documented and approved by the appropriate risk owner.
17. Risk Treatment Plan
| Risk ID | Treatment Action | Control | Owner | Priority | Target Date | Status | Evidence |
|---|---|---|---|---|---|---|---|
| PR-001 | Enforce MFA for privileged AWS users | Access Control | Cloud Lead | Critical | [Date] | Open | IAM evidence |
| PR-002 | Encrypt production database | Data Protection | Cloud Lead | High | [Date] | Open | AWS configuration |
| PR-003 | Upgrade vulnerable dependency | Vulnerability Management | Engineering | Critical | [Date] | Open | Scan report |
| PR-004 | Move CI/CD secrets to secure vault | Secret Management | DevOps | High | [Date] | Open | Configuration |
18. Residual Risk Assessment
After treatment, reassess the risk.
| Risk ID | Initial Risk | Treatment | Residual Likelihood | Residual Impact | Residual Risk | Acceptance |
|---|---|---|---|---|---|---|
| PR-001 | 20 Critical | MFA + Least Privilege | 2 | 5 | 10 High | Review |
| PR-002 | 15 High | Encryption + IAM | 2 | 5 | 10 High | Review |
| PR-003 | 20 Critical | Dependency Upgrade | 2 | 5 | 10 High | Review |
A control may reduce likelihood without changing the potential impact.
For example, if unauthorized access to a customer database could still have severe consequences, the impact score may remain high even after strong preventive controls are implemented.
Residual risk should be compared against the organization’s approved risk acceptance criteria.
19. Detailed Project Risk Record
For significant risks, maintain a detailed record.
Risk ID
PR-001
Asset
AWS Production Environment
Threat
Compromise of privileged credentials.
Vulnerability
Excessive privileges and insufficient privileged access controls.
Risk Event
An attacker obtains privileged credentials and gains unauthorized access to production AWS resources.
Potential Impact
- Unauthorized system changes
- Service disruption
- Customer data exposure
- Security incident
- Regulatory or contractual consequences
Existing Controls
- MFA
- IAM
- Least privilege
- CloudTrail
- Cloud monitoring
Initial Assessment
Likelihood: 4
Impact: 5
Risk: 20 – Critical
Treatment
- Enforce MFA.
- Remove unnecessary privileges.
- Separate administrative roles.
- Review privileged access.
- Monitor privileged activity.
Residual Assessment
Likelihood: 2
Impact: 5
Residual Risk: 10 – High
Risk Owner
Cloud / Technology Owner
Evidence
- IAM configuration
- MFA configuration
- Access approvals
- Access review
- CloudTrail logs
- Monitoring alerts
20. Project Risk and Security Requirements
Project security requirements should be linked to project risks.
| Risk | Security Requirement | Control | Verification |
|---|---|---|---|
| Compromised credentials | MFA required | IAM/MFA | Configuration review |
| Data exposure | Database encryption | Encryption | AWS evidence |
| Application exploitation | Vulnerability testing | Security Testing | Scan/VAPT report |
| Unauthorized deployment | Deployment approval | Change Management | Change record |
This creates:
Risk → Requirement → Control → Implementation → Verification
21. Project Risk and Threat Intelligence
Threat intelligence may change the project risk assessment.
Example:
Threat Intelligence
Active exploitation of a vulnerability affecting the project’s technology stack.
↓
Project Assessment
The affected component is used by the project and is internet-facing.
↓
Risk Update
Likelihood increased due to active exploitation.
↓
Treatment
Immediate remediation and security testing.
↓
Verification
Vulnerability scan confirms remediation.
The Project Risk Assessment should therefore be updated when significant threat intelligence changes the risk.
22. Project Risk and Vulnerability Management
Vulnerabilities identified during:
- Development
- Security testing
- VAPT
- Code scanning
- Dependency scanning
- Cloud security review
- Penetration testing
should be assessed for project risk.
Not every vulnerability automatically represents the same level of business risk.
Consider:
Technical Severity + Exposure + Asset Criticality + Data + Existing Controls + Business Impact
23. Third-Party Project Risks
Where third parties are involved, consider:
- Supplier security
- Data access
- Supplier credentials
- API integration
- Data transfer
- Supplier availability
- Security incident notification
- Subcontractors
- Dependency risk
- Exit/termination risk
Example
A critical third-party API becomes unavailable, preventing the project application from processing customer transactions.
Potential treatments:
- Supplier SLA
- Redundancy
- Monitoring
- Alternative provider
- Business continuity plan
- Contractual requirements
24. Change in Project Scope
The risk assessment should be reviewed when there is a significant change.
Examples:
- New technology
- New cloud service
- New type of data
- New customer requirement
- New supplier
- Major architecture change
- New geographic deployment
- New regulatory requirement
- Production architecture change
- Major security incident
A significant change may require reassessment before proceeding.
25. Risk Review Points
Recommended review points include:
| Project Stage | Risk Activity |
|---|---|
| Initiation | Identify major risks |
| Planning | Complete initial assessment |
| Design | Review architecture risks |
| Development | Review emerging risks |
| Testing | Incorporate security findings |
| Pre-Production | Reassess residual risks |
| Production | Confirm accepted risks |
| Closure | Transfer ongoing risks |
| Major Change | Reassess affected risks |
The actual frequency should be based on project risk and organizational methodology.
26. Risk Acceptance
Where residual risk remains, document acceptance where required.
| Field | Details |
|---|---|
| Risk ID | [PR-XXX] |
| Residual Risk | [Risk] |
| Reason for Acceptance | [Business Reason] |
| Existing Controls | [Controls] |
| Residual Risk Level | [Level] |
| Risk Owner | [Name] |
| Approval Authority | [Name] |
| Acceptance Date | [Date] |
| Review Date | [Date] |
| Expiry Date | [If Applicable] |
Risk acceptance should be consistent with the organization’s risk acceptance criteria.
27. Project Risk Summary
At the end of the assessment, summarize the project risk profile.
| Risk Level | Number |
|---|---|
| Critical | [#] |
| High | [#] |
| Medium | [#] |
| Low | [#] |
Key Project Risks
- [Risk]
- [Risk]
- [Risk]
Major Treatment Actions
- [Action]
- [Action]
- [Action]
Outstanding Risks
[Describe unresolved risks.]
Management Decision
[Proceed / Proceed with conditions / Further treatment required — according to organization’s approval process.]
28. Project Risk Sign-Off
Risk Assessor
Name: ______________________
Role: ______________________
Signature/Approval: ______________________
Date: ______________________
Project Manager
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
Risk Owner
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
Management / Approver
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
29. Audit Evidence
The following may be retained as evidence:
- Project Risk Assessment
- Risk Register
- Risk methodology
- Asset inventory
- Security requirements
- Architecture diagrams
- Data-flow diagrams
- Threat assessments
- Threat intelligence
- Vulnerability reports
- VAPT reports
- Security testing
- Treatment plans
- Risk acceptance
- Access reviews
- Cloud configuration evidence
- Change records
- Security approvals
- Project closure records
The auditor should be able to trace:
Project → Asset → Threat → Vulnerability → Risk → Control → Treatment → Residual Risk → Acceptance/Action → Evidence
30. Project Risk Assessment Checklist
- ☐ Project scope defined
- ☐ Assets identified
- ☐ Information identified
- ☐ Data classification completed
- ☐ Threats identified
- ☐ Vulnerabilities/weaknesses identified
- ☐ Risk events documented
- ☐ Impact assessed
- ☐ Likelihood assessed
- ☐ Initial risk calculated
- ☐ Existing controls identified
- ☐ Treatment selected
- ☐ Treatment actions assigned
- ☐ Owners identified
- ☐ Treatment completed/monitored
- ☐ Residual risk assessed
- ☐ Risk acceptance obtained where required
- ☐ Threat intelligence considered
- ☐ Vulnerability findings considered
- ☐ Major project changes reassessed
- ☐ Evidence retained
- ☐ Final approval completed
31. Startup-Friendly Approach
For a small SaaS project, the risk assessment does not need to become a large documentation exercise.
A practical approach is:
Identify Project Assets
↓
Identify What Could Go Wrong
↓
Assess Likelihood and Impact
↓
Identify Existing Controls
↓
Determine Additional Treatment
↓
Assign Risk Owners
↓
Implement Controls
↓
Verify
↓
Assess Residual Risk
↓
Accept or Treat Further
↓
Monitor During the Project
The level of detail should increase when the project involves critical systems, sensitive information, significant customer impact, complex technology, or high-risk suppliers.
32. Relationship With Other ISMS Documents
The Project Risk Assessment should connect with:
- Project Security Requirements Template
- Project Security Checklist
- Information Security Risk Assessment
- Risk Register
- Asset Register
- Threat Assessment
- Threat Intelligence Register
- Vulnerability Register
- Incident Register
- Supplier Security Assessment
- Secure Development Procedure
- Change Management Procedure
- Business Continuity Plan
- Statement of Applicability
The overall relationship is:
Project → Security Requirements → Threats → Risks → Controls →