Build privacy and security gates into an IT project plan from the start, and know which laws and standards to ask about.
Why it matters
Security and privacy problems found the week before go-live are among the most expensive surprises an IT project can have. A penetration test that finds serious flaws, a privacy review that says you cannot store certain data, or an auditor asking for evidence you never collected can each delay launch by weeks. Worse, problems that reach production can harm real people and bring fines. The fix is simple to describe: plan security and compliance as gates in the project from the start, with time and owners, just like testing. This is often called "shifting left" or security by design and privacy by design.
You are not expected to be the security expert. You are expected to involve the experts early, give them time in the plan, and make sure their requirements are treated as real requirements.
Which rules apply?
Ask your security, privacy and legal teams early which laws, regulations and standards apply. Common ones for IT projects include:
- Privacy laws such as the EU and UK GDPR, and state laws such as the California Consumer Privacy Act (CCPA). These set rules on collecting, using, keeping and deleting personal data.
- Sector rules, for example HIPAA for health information in the US, or PCI DSS if the system handles payment card data.
- Assurance frameworks customers may ask for, such as SOC 2 reports or ISO/IEC 27001 certification.
- Accessibility requirements (for example WCAG conformance in public-sector contracts) are often handled alongside compliance.
- Internal policies: data classification, retention, approved cloud providers, change management.
The details of these rules change and depend on where you operate. Do not interpret them yourself: record the requirement, name an owner in the relevant team, and plan the work.
Security and privacy gates across the lifecycle
| Phase | Gate or activity | Typical owner |
|---|---|---|
| Initiation | Data classification: what data will we handle? Is personal or sensitive data involved? | Product owner with privacy team |
| Initiation | Privacy impact assessment (a DPIA under GDPR) if personal data is high risk | Privacy officer |
| Requirements | Security and privacy requirements written as backlog items or requirements, with acceptance criteria | Security architect, business analyst |
| Design | Architecture and threat modelling review: how could this be attacked? | Security architect, lead engineer |
| Vendor selection | Vendor security questionnaire, contract clauses (data processing agreement, breach notification) | Procurement, security |
| Build | Secure coding practices, code review, automated scanning of code and dependencies | Engineering team |
| Test | Security testing, and a penetration test for internet-facing systems | Security team or external testers |
| Go-live | Security sign-off, access reviews, logging and monitoring in place, incident response contacts | Security, operations |
| Closure | Evidence filed for auditors; retention and deletion rules working | Project lead, compliance |
Worked example: Northside Clinics
The portal handles patient names, contact details and appointment types, which is health-related personal data. At initiation, you:
- Ask the privacy officer whether a privacy impact assessment is needed. It is, and it takes three weeks, so it goes on the critical path before design sign-off.
- Add security requirements to the backlog: multi-factor sign-in for staff, encryption in transit and at rest, audit logs of who viewed which booking, and deletion of cancelled bookings after the agreed retention period.
- Book an external penetration test six weeks before go-live, with two weeks after it reserved for fixes.
- Make sure the kiosk vendor contract includes a data processing agreement and breach notification terms.
When the penetration test finds one high-severity issue, there is time to fix and retest without moving the launch.
Data minimisation: the cheapest control
The safest data is data you never collect. Ask, for each field: do we need it, for how long, and who needs to see it? The Northside team dropped date of birth from the booking form for returning patients because the records system already had it, which removed a privacy risk at zero cost.
Common mistakes
- Booking the penetration test the week before go-live, with no time to fix findings.
- Treating security requirements as "non-functional" extras that get cut when time is short.
- Copying production data, including real personal data, into test environments without approval.
- Assuming a cloud provider handles all compliance. Under the shared responsibility model, the provider secures its infrastructure; you remain responsible for how you configure and use it.
Quick recap
- Plan security and privacy as gates with owners and time, from initiation to closure.
- Ask the experts which laws and standards apply; record them as requirements.
- Threat model in design, scan and review in build, penetration test with time to fix.
- Collect only the data you need, and keep evidence for auditors.
Try it
Open the Do tab and test yourself on where security and compliance fit in a project.