🗂️🔒1. Data Minimization & Lifecycle Management

This is about controlling how much data you have, how long you keep it, and where it lives.

What it involves:

• Collect only what’s necessary (no “just in case” data)
• Define retention policies (e.g., delete after X days/months/years)
• Automatically archive or securely delete old data
• Apply different controls based on data sensitivity

Where teams fail:

• Keeping data indefinitely
• Forgetting about backups, logs, exports, and test datasets
• Not deleting data after customer offboarding

Best practice:

● Regularly audit for “data sprawl”

● Tie data retention directly to legal, regulatory, and business needs

● Automate deletion and anonymization

🏗️🛡️2. Secure by Design, Not After the Fact

Security must be built into architecture—not bolted on later.

What it involves:

• Threat modeling during design phases
• Secure architecture reviews before development
• Embedding security requirements into user stories and pipelines

Where teams fail:

• Treating security as a final QA step
• Retrofitting controls after deployment (expensive and incomplete)

Best practice:

● Make security a requirement, not an enhancement

● Integrate security into the SDLC (DevSecOps)

● Use secure design patterns and reference architectures

👤🔐3. Human-Centered Security

Security controls must work with people, not against them.

What it involves:

• Designing usable authentication (e.g., MFA that isn’t overly painful)
• Reducing friction that leads to workarounds
• Training based on real-world threats (phishing, social engineering)

Where teams fail:

• Overly complex policies (users bypass them)
• One-time annual training with no reinforcement

Best practice:

● Minimize reliance on human memory or manual steps

● Design for usability and behavior, not just policy

● Use phishing simulations and continuous awareness

🔍✅4. Verify, Don’t Just Trust Controls

Controls must be tested and validated regularly.

What it involves:

• Testing backups via real restores
• Validating alerting and monitoring systems
• Running tabletop exercises and simulations
• Performing access reviews

Where teams fail:

• Assuming controls work because they exist
• Never testing incident response or recovery

Best practice:

● Treat testing as part of operations, not a one-time effort

● Continuously validate controls in real conditions

🧱🔄5. Resilience Over Prevention

Prevention is important—but failure is inevitable.

What it involves:

• Designing systems to:
  • detect quickly
  • contain damage
  • recover fast
• Defining and meeting:
  • RTO (Recovery Time Objective)
  • RPO (Recovery Point Objective)

Where teams fail:

• Over-investing in prevention, under-investing in recovery
• No clear recovery strategy during incidents

Best practice:

● Build systems that degrade gracefully, not catastrophically

● Assume compromise will happen

● Focus equally on detection, response, and recovery

🔑🧰 6. Secrets Management Discipline

Credentials are one of the most exploited weaknesses.

What it involves:

• Centralized secrets management (vaults)
• No hardcoded credentials in code or configs
• Regular rotation of secrets
• Tight access control and auditing

Where teams fail:

• Secrets stored in:
  • source code
  • environment files
  • scripts
• Rarely rotated credentials

Best practice:

● Monitor usage for anomalies

● Use dynamic or short-lived secrets where possible

● Automate rotation and revocation

🌐🧠7. Context-Aware Access (Adaptive Security)

Access decisions should consider context, not just identity.

What it involves:

• Evaluating:
  • device health
  • location
  • time of access
  • behavioral patterns
• Adjusting controls dynamically (step-up authentication, blocking, etc.)

Where teams fail:

• Binary access decisions (allowed/denied only)
• No adaptation to risk signals

Best practice:

● Combine with Zero Trust principles

● Implement risk-based authentication

● Trigger stronger controls when anomalies are detected

🔗🚚8. Third-Party & Supply Chain Awareness

Vendors and dependencies are part of your attack surface.

What it involves:

• Assessing vendor security posture
• Limiting vendor access to only what’s necessary
• Monitoring third-party integrations
• Managing software dependencies and updates

Where teams fail:

• Trusting vendors without verification
• Excessive permissions for integrations
• Ignoring supply chain risks (libraries, packages, plugins)

Best practice:

● Continuously monitor—not just at onboarding

● Maintain an inventory of third parties and dependencies

● Require security standards and reviews

📜🚨9. Logging for Detection, Not Just Compliance

Logging should help you detect and respond, not just “check a box.”

What it involves:

• Capturing meaningful, high-value events:
  • authentication attempts
  • privilege changes
  • data access
• Centralizing logs for correlation
• Building actionable alerts

Where teams fail:

• Logging too much noise or too little signal
• Logs are stored but never reviewed
• Alerts that no one responds to

Best practice:

● Regularly review and improve detection logic

● Focus on useful, actionable telemetry

● Tune alerts to reduce noise

👥👁️10. Non-Named Accounts (Service, Shared, Automation) Should Be Minimized, Tightly Controlled, and Heavily Monitored

Non-named accounts are high-risk because they often lack strong authentication, have excessive privileges, and limited accountability—making them a common attack path.

What this involves:

• Minimize use; prefer named users or managed/ephemeral identities
• Assign a clear owner and defined purpose for every account
• Enforce least privilege and restrict scope (systems, environments)
• Store credentials securely (no hardcoding) and rotate regularly
• Log and monitor all activity

Common failure:

• Too many service/shared accounts with no clear ownership
• Long-lived or hardcoded credentials
• Overprivileged access “for convenience”
• Little to no monitoring or review
• Dormant accounts left active indefinitely

Best practice:

● Automatically disable unused accounts

● Replace with short-lived (ephemeral) credentials wherever possible

● Require ownership, justification, and periodic review

● Enforce strict access controls and secure secrets management

● Monitor closely and alert on abnormal behavior

💾🔁11. Review Backup Logs and Test Backup Restoration

Backups are useless if you can’t reliably restore from them.

What this involves:

• Regularly reviewing backup job logs for:
  • failures
  • partial backups
  • skipped files/systems
• Performing scheduled restore tests (not just checking that backups exist)
• Verifying:
  • data integrity
  • recovery time (RTO)
  • recovery point (RPO)

Common failure:
Teams assume backups work because jobs say “successful”—but:

• data is corrupted
• restores are incomplete
• recovery takes too long during an incident

Best practice:
Treat restore testing like a fire drill:

• automate where possible
• test critical systems more frequently
• document and improve recovery procedures

🏷️📊 12. Identify and classify data for compliance needs (Ex: PII & PHI privacy data identified for GDPR and HIPAA)

You can’t protect data properly if you don’t know what it is.

What this involves:

• Discovering and labeling sensitive data such as:
  • PII (Personally Identifiable Information)
  • PHI (Protected Health Information)
• Mapping where data lives:
  • databases
  • file storage
  • SaaS platforms
• Aligning controls to regulatory requirements like:
  • General Data Protection Regulation (GDPR)
  • Health Insurance Portability and Accountability Act (HIPAA)

Common failure:

• “We encrypt everything” → but don’t know where sensitive data actually resides
• Shadow data in exports, logs, backups

Best practice:

● Continuously scan for sensitive data sprawl

● Use classification tiers (e.g., Public / Internal / Confidential / Restricted)

● Apply controls based on classification (encryption, access, retention)

🖥️🛡️13. OS and Application Hardening Standards

Out-of-the-box configurations are rarely secure.

What this involves:

• Defining baseline configurations for:
  • operating systems
  • databases
  • applications
• Removing or disabling:
  • unnecessary services
  • default accounts
  • unused ports and protocols
• Enforcing:
  • patch levels
  • secure configurations
  • configuration drift detection

Common failure:

• “Golden images” created once and never updated
• Inconsistent configurations across environments

Best practice:

● Use established benchmarks (like CIS benchmarks)

● Implement configuration as code

● Continuously monitor and remediate drift

🧑‍💻🚫14. Restrict Admin privileges

Admin access is one of the most exploited attack paths.

What this involves:

• Limiting who has administrative rights
• Separating:
  • standard user accounts
  • privileged/admin accounts
• Using:
  • Just-in-Time (JIT) elevation
  • approval workflows
  • session monitoring

Common failure:

• Users with permanent admin rights “for convenience”
• Admin accounts used for email/web browsing

Best practice:

• Enforce least privilege strictly
• Require MFA for all privileged access
• Log and monitor all admin activity

Regularly review and remove unnecessary privileges

🤖⛔15. Restrict RPA, macros and other automated services such as data integration

Automation is powerful—but also a major hidden attack vector.

What this includes:

• Robotic Process Automation (RPA) bots
• Office macros (e.g., Excel, Word)
• Data integration tools and scripts
• Scheduled jobs and workflows

Risks:

• Often run with high privileges
• May use hardcoded credentials
• Can execute malicious actions at scale
• Frequently bypass normal user controls

Common failure:

• “It’s just automation” → treated as low risk
• No visibility into what bots/scripts actually do

Best practice:

• Treat automation like service accounts:
  • assign least privilege
  • avoid shared credentials
  • use secure secret storage
• Disable macros by default; allow only signed/approved ones
• Monitor behavior and execution logs

Restrict where automation can run and what it can access