1. Purpose

The Project Security Checklist is used to ensure that information security requirements are identified, assessed, implemented, and verified throughout the lifecycle of a project.

The checklist helps ensure that security is considered before, during, and after project activities rather than being addressed only at the end.

It can be used for:

• New software development
• Major application changes
• Cloud migrations
• New cloud environments
• New customer implementations
• New products or services
• Infrastructure projects
• Technology implementations
• Major system upgrades
• Third-party technology implementations
• Business process changes involving sensitive information

---

2. Objectives

The checklist helps the project team:

• Identify security requirements early.
• Identify information and assets involved.
• Assess project-related security risks.
• Define appropriate security controls.
• Protect confidential and sensitive information.
• Apply access control and segregation of duties.
• Address privacy and regulatory requirements.
• Secure development and testing activities.
• Manage suppliers and third parties.
• Validate security before production deployment.
• Maintain evidence of security decisions and activities.

---

3. When to Use the Checklist

The checklist should be completed during project planning and updated as the project progresses.

Recommended checkpoints:

Project Initiation → Planning → Design → Development → Testing → Deployment → Closure

The level of assessment should be proportionate to the project’s:

• Size
• Complexity
• Risk
• Data sensitivity
• Technology
• Business criticality
• Customer impact
• Regulatory requirements

A small internal project does not necessarily require the same level of security review as a customer-facing system processing sensitive information.

---

4. Project Information

Field	Details
Project Name	[Project Name]
Project ID	[Project ID]
Project Manager	[Name]
Security Owner	[Name]
Business Owner	[Name]
Technical Owner	[Name]
Start Date	[Date]
Target Completion	[Date]
Project Type	[Development / Migration / Implementation / Other]
ISMS Scope	[Yes / No]
Data Classification	[Public / Internal / Confidential / Restricted]
Criticality	[Low / Medium / High / Critical]
Third Parties	[Yes / No]
Security Review Required	[Yes / No]
Privacy Review Required	[Yes / No]
Status	[Planning / Development / Testing / Production / Closed]

---

5. Security Requirements

#	Security Check	Status	Evidence / Remarks
1	Security requirements identified	☐
2	Business requirements reviewed for security implications	☐
3	Applicable legal/regulatory requirements identified	☐
4	Customer/contractual security requirements identified	☐
5	Privacy requirements assessed	☐
6	Data classification determined	☐
7	Security acceptance criteria defined	☐
8	Security responsibilities assigned	☐

---

6. Information and Asset Identification

Identify the information and assets involved in the project.

Asset / Information	Owner	Classification	Criticality	Security Requirement
Customer database	Data Owner	Confidential	High	Encryption / Access Control
Source code	Engineering	Confidential	High	Repository Access
AWS production environment	Cloud Team	Restricted	Critical	MFA / Logging
API credentials	Security	Restricted	Critical	Secure Secret Storage

Check that:

• ☐ Information assets are identified.
• ☐ Asset owners are identified.
• ☐ Information classification is defined.
• ☐ Critical systems are identified.
• ☐ Dependencies are documented.
• ☐ Data flows are understood where relevant.

---

7. Security Risk Assessment

The project team should determine whether the project introduces new or changed information security risks.

Risk Assessment Questions

• What could go wrong?
• What information could be exposed?
• Which systems could be compromised?
• Who could gain unauthorized access?
• Could the project introduce new vulnerabilities?
• Could a third party create additional risk?
• Could availability be affected?
• Could privacy requirements be affected?
• Could customer commitments be affected?

Risk Record

Risk ID	Risk	Likelihood	Impact	Risk Level	Treatment	Owner
PR-001	Unauthorized access to project data	4	5	Critical	Reduce	Security Lead
PR-002	Vulnerable third-party dependency	3	4	High	Reduce	Engineering
PR-003	Production deployment failure	3	4	High	Reduce	DevOps

The organization’s approved risk methodology should be used.

---

8. Project Roles and Responsibilities

Confirm that responsibilities are clearly assigned.

• ☐ Project Manager
• ☐ Business Owner
• ☐ Security Owner
• ☐ Technical Owner
• ☐ Data Owner
• ☐ System Owner
• ☐ Vendor/Supplier Owner
• ☐ Testing/QA Owner
• ☐ Approval authority

Where practical, avoid situations where the same person can develop, approve, deploy, and independently verify a high-risk change without appropriate compensating controls.

---

9. Access Control

Confirm that project access is appropriately controlled.

• ☐ Access is based on business need.
• ☐ Least privilege is applied.
• ☐ Role-based access is used where appropriate.
• ☐ MFA is enabled for privileged/sensitive access.
• ☐ Development and production access are separated where appropriate.
• ☐ Privileged access is restricted.
• ☐ Access approvals are documented.
• ☐ Temporary access has an expiry date.
• ☐ Third-party access is controlled.
• ☐ Access is reviewed periodically.
• ☐ Access is removed when no longer required.

---

10. Secure Development

For software projects:

• ☐ Secure development requirements defined.
• ☐ Secure coding practices established.
• ☐ Code repository access restricted.
• ☐ Branch protection implemented where appropriate.
• ☐ Code review performed.
• ☐ Secrets are not stored in source code.
• ☐ Dependencies are identified.
• ☐ Dependency vulnerabilities are monitored.
• ☐ Static code analysis performed where appropriate.
• ☐ Dynamic/application security testing performed where appropriate.
• ☐ Security defects are tracked.
• ☐ Security testing results are reviewed before release.

---

11. Environment Security

Where development, testing, staging, and production environments exist:

• ☐ Environments are appropriately separated.
• ☐ Production access is restricted.
• ☐ Production data is not unnecessarily copied to non-production environments.
• ☐ Sensitive test data is protected.
• ☐ Test accounts are controlled.
• ☐ Test credentials are not reused in production.
• ☐ Configuration differences are understood.
• ☐ Production deployment requires appropriate authorization.

---

12. Cloud Security

For cloud projects:

• ☐ Cloud architecture reviewed for security.
• ☐ Cloud accounts/subscriptions/projects are appropriately separated.
• ☐ IAM roles reviewed.
• ☐ MFA enabled for privileged users.
• ☐ Network access controls configured.
• ☐ Security groups/firewall rules reviewed.
• ☐ Encryption requirements addressed.
• ☐ Logging enabled.
• ☐ Monitoring configured.
• ☐ Backup requirements addressed.
• ☐ Secrets stored securely.
• ☐ Cloud resources are inventoried.
• ☐ Public exposure is reviewed.
• ☐ Security configuration is tested.

AWS Example

For an AWS SaaS project, review:

• IAM
• Organizations/accounts
• VPC
• Security Groups
• S3
• RDS
• CloudTrail
• CloudWatch
• KMS
• Secrets Manager
• WAF
• Backup
• GuardDuty/Security Hub where applicable

The exact services should depend on the project architecture.

---

13. Data Protection

Confirm that project data is appropriately protected.

• ☐ Data classification completed.
• ☐ Data collection is appropriate.
• ☐ Data storage locations identified.
• ☐ Data transmission is protected.
• ☐ Encryption requirements assessed.
• ☐ Access restrictions implemented.
• ☐ Sensitive data exposure risks assessed.
• ☐ Data retention requirements defined.
• ☐ Data deletion requirements defined.
• ☐ Backup requirements defined.
• ☐ Test data is appropriately protected.
• ☐ Data transfer requirements assessed.

---

14. Privacy

Where personal data is involved:

• ☐ Personal data identified.
• ☐ Purpose of processing documented.
• ☐ Applicable privacy requirements identified.
• ☐ Privacy impact assessed where appropriate.
• ☐ Data minimization considered.
• ☐ Access requirements reviewed.
• ☐ Retention requirements defined.
• ☐ Third-party processing assessed.
• ☐ Cross-border transfer requirements assessed where applicable.
• ☐ Privacy notices/consent requirements reviewed where applicable.

---

15. Third-Party and Supplier Security

Where suppliers are involved:

• ☐ Supplier identified.
• ☐ Security requirements defined.
• ☐ Supplier security assessment performed where appropriate.
• ☐ Contractual security requirements included.
• ☐ Confidentiality requirements addressed.
• ☐ Data processing requirements addressed.
• ☐ Supplier access controlled.
• ☐ Supplier integration reviewed.
• ☐ Incident notification requirements defined.
• ☐ Supplier exit requirements considered.

---

16. Vulnerability Management

Before deployment:

• ☐ Vulnerability scanning completed where applicable.
• ☐ Application security testing completed where applicable.
• ☐ Infrastructure security testing completed where applicable.
• ☐ Dependencies reviewed.
• ☐ Critical/high vulnerabilities assessed.
• ☐ Security findings assigned to owners.
• ☐ Required remediation completed.
• ☐ Residual risks documented and approved where necessary.
• ☐ Remediation verified.

---

17. Change Management

Project changes should follow the organization’s change management process.

• ☐ Changes are documented.
• ☐ Changes are reviewed.
• ☐ Security impact is assessed where necessary.
• ☐ Changes are tested.
• ☐ Appropriate approval is obtained.
• ☐ Emergency changes are controlled.
• ☐ Deployment records are retained.
• ☐ Rollback procedures are available for important changes.

---

18. Backup and Recovery

Where applicable:

• ☐ Backup requirements identified.
• ☐ Critical data is backed up.
• ☐ Backup access is restricted.
• ☐ Backup protection is implemented.
• ☐ Recovery requirements defined.
• ☐ Recovery testing performed where appropriate.
• ☐ Recovery procedures documented.
• ☐ Business continuity requirements considered.

---

19. Logging and Monitoring

Confirm that appropriate security monitoring is available.

• ☐ Security-relevant events are logged.
• ☐ Authentication events are logged where appropriate.
• ☐ Privileged activities are logged.
• ☐ Important administrative actions are logged.
• ☐ Application security events are monitored where appropriate.
• ☐ Logs are protected from unauthorized modification.
• ☐ Log retention requirements are defined.
• ☐ Alerts are configured for important security events.
• ☐ Monitoring responsibilities are assigned.

---

20. Incident Response

Confirm that the project can be supported by the organization’s incident response process.

• ☐ Security incident scenarios identified.
• ☐ Incident reporting mechanism available.
• ☐ Security contacts identified.
• ☐ Escalation requirements defined.
• ☐ Customer notification requirements considered.
• ☐ Regulatory notification requirements considered where applicable.
• ☐ Evidence preservation requirements considered.
• ☐ Incident response procedures tested where appropriate.

---

21. Security Testing

Security testing should be proportionate to project risk.

Possible testing includes:

• Code review
• SAST
• DAST
• Dependency scanning
• Vulnerability scanning
• Configuration review
• Cloud security review
• VAPT
• Penetration testing
• API security testing
• Authentication testing
• Authorization testing
• Infrastructure testing

Testing results should be reviewed before production deployment.

---

22. Production Readiness Security Review

Before production deployment, confirm:

• ☐ Security requirements completed.
• ☐ Critical security findings resolved.
• ☐ Remaining risks documented.
• ☐ Required risk acceptance obtained.
• ☐ Access controls implemented.
• ☐ Logging enabled.
• ☐ Monitoring enabled.
• ☐ Backup/recovery configured.
• ☐ Incident response prepared.
• ☐ Security testing completed.
• ☐ Security approvals obtained.
• ☐ Deployment/change approval obtained.

---

23. Project Security Sign-Off

Security Owner

Name: ______________________

Signature/Approval: ______________________

Date: ______________________

Project Manager

Name: ______________________

Signature/Approval: ______________________

Date: ______________________

Business Owner

Name: ______________________

Signature/Approval: ______________________

Date: ______________________

Security Exceptions / Residual Risks

ID	Exception / Risk	Reason	Compensating Control	Owner	Approval	Review Date
EX-001	[Description]	[Reason]	[Control]	[Owner]	[Approver]	[Date]

---

24. Project Closure

At project completion:

• ☐ Project security requirements reviewed.
• ☐ Outstanding security findings addressed.
• ☐ Residual risks transferred to the appropriate owner.
• ☐ Temporary accounts removed.
• ☐ Temporary access removed.
• ☐ Temporary infrastructure removed.
• ☐ Project secrets/credentials reviewed.
• ☐ Documentation completed.
• ☐ Security evidence retained.
• ☐ Lessons learned recorded.
• ☐ Asset inventory updated.
• ☐ Risk Register updated where required.
• ☐ Supplier information updated where required.
• ☐ Operational teams received necessary handover information.

---

25. Evidence Checklist

Typical evidence may include:

• Project security requirements
• Project risk assessment
• Architecture diagrams
• Data-flow diagrams
• Security design review
• Access approvals
• Access review records
• Code review records
• Security testing reports
• Vulnerability scan reports
• Penetration testing reports
• Change records
• Deployment approvals
• Cloud configuration evidence
• Logging/monitoring configuration
• Backup/recovery testing
• Supplier assessments
• Privacy assessment
• Risk acceptance
• Security sign-off
• Project closure report

---

26. AWS SaaS Project Example

Consider a startup launching a new customer-facing SaaS application on AWS.

Project

New Customer Analytics Platform

Security Review

The project team identifies:

• Customer data
• AWS production environment
• Application source code
• APIs
• Database
• Developer access
• Third-party APIs

Security Requirements

The team establishes:

• MFA for privileged AWS access
• Least-privilege IAM
• Encryption
• Secure API authentication
• Logging and monitoring
• Vulnerability scanning
• Code review
• Backup and recovery
• Incident response
• Customer data protection

Before Go-Live

The team completes:

Security Design → Risk Assessment → Secure Development → Security Testing → Vulnerability Remediation → Access Review → Production Security Review → Approval → Deployment

The checklist provides evidence that security was considered throughout the project lifecycle.

---

27. Startup-Friendly Approach

A startup does not need to turn every project into a large compliance exercise.

For a normal software project, the minimum practical process can be:

1. Identify the project and data

↓

2. Identify security requirements

↓

3. Assess security risks

↓

4. Design appropriate controls

↓

5. Implement security controls

↓

6. Perform security testing

↓

7. Resolve important findings

↓

8. Obtain security approval

↓

9. Deploy

↓

10. Monitor

↓

11. Close and capture lessons learned

The depth of the checklist should increase with project risk.

---

28. Relationship With Other ISMS Documents

The Project Security Checklist should connect with:

• Information Security Policy
• Risk Assessment
• Risk Register
• Asset Register
• Access Control Policy
• Secure Development Procedure
• Change Management Procedure
• Vulnerability Management Procedure
• Supplier Security Procedure
• Data Classification Policy
• Data Privacy Policy
• Incident Management Procedure
• Business Continuity Plan
• Threat Intelligence Procedure
• Security Testing/VAPT Procedure
• Statement of Applicability

The relationship can be summarized as:

Project → Requirements → Risk → Controls → Implementation → Testing → Evidence → Approval → Monitoring

---

29. Final Audit Checklist

Before closing the project, confirm:

Area	Complete
Security requirements identified	☐
Project risks assessed	☐
Assets identified	☐
Data classified	☐
Access controls implemented	☐
Secure development requirements addressed	☐
Supplier risks assessed	☐
Privacy requirements assessed	☐
Vulnerabilities assessed	☐
Security testing completed	☐
Critical findings addressed	☐
Logging and monitoring configured	☐
Backup/recovery addressed	☐
Incident response addressed	☐
Residual risks documented	☐
Required approvals obtained	☐
Security evidence retained	☐
Project closure completed	☐

---

30. Final Principle

Project security should not be a final-stage compliance check.

The objective is:

Plan Security → Assess Risk → Design Controls → Build Securely → Test → Approve → Deploy → Monitor → Improve

The key question is:

“Have security requirements and risks been considered throughout the project lifecycle, and can the organization demonstrate that appropriate controls were implemented and verified?”