Top SaaS Security Checklist for Developers

Your startup just landed its first enterprise customer—a $50,000 annual contract. Their security team requests your SOC 2 report, penetration test results, and documentation of your encryption practices. You have none of these because you prioritized shipping features over security infrastructure. The deal dies, and with it, six months of sales effort. This scenario costs early-stage SaaS companies millions in lost enterprise revenue every year, yet most security requirements are straightforward to implement if you build them in from the start.

This article provides a comprehensive security checklist for SaaS developers covering authentication, authorization, data protection, infrastructure security, and compliance readiness. You'll learn which security measures are non-negotiable for any SaaS product, which ones become critical as you move upmarket to enterprise customers, and how to implement them without derailing your development velocity. The patterns here prevent the common vulnerabilities that appear in penetration test reports and security questionnaires.

We'll organize security requirements into three tiers: foundational security that every SaaS product must have before launch, growth-stage security needed to close mid-market deals, and enterprise security required for large customer contracts and compliance certifications.

Authentication: Password Security and Session Management

Authentication security starts with password storage. Never store plaintext passwords or use weak hashing algorithms like MD5 or SHA-1. Use bcrypt, scrypt, or Argon2 with appropriate work factors that balance security against server CPU cost. Bcrypt with cost factor 12 is the current standard—it takes approximately 300ms to hash a password, making brute force attacks impractical while keeping login times acceptable.

// Secure password hashing with bcrypt
const bcrypt = require('bcrypt');

const SALT_ROUNDS = 12; // Cost factor

async function hashPassword(password) {
  // Validate password strength before hashing
  if (password.length < 8) {
    throw new Error('Password must be at least 8 characters');
  }

  return bcrypt.hash(password, SALT_ROUNDS);
}

async function verifyPassword(password, hash) {
  return bcrypt.compare(password, hash);
}

// At registration
app.post('/api/auth/register', async (req, res) => {
  const { email, password } = req.body;

  // Additional validation: check against common passwords
  if (isCommonPassword(password)) {
    return res.status(400).json({
      error: 'Password is too common. Choose a stronger password.'
    });
  }

  const passwordHash = await hashPassword(password);

  await db.query(
    'INSERT INTO users (email, password_hash) VALUES ($1, $2)',
    [email, passwordHash]
  );

  res.json({ success: true });
});

Password policies balance security and user experience. Require minimum 8 characters, but don't enforce maximum lengths (bcrypt handles up to 72 bytes). Check passwords against lists of commonly breached passwords using services like HaveIBeenPwned's API or local databases. Don't require special characters or numbers—research shows these rules encourage predictable patterns (like adding "1!" to passwords) without improving security.

Session management requires secure token generation and storage. Use cryptographically secure random tokens for session IDs, never predictable sequences or timestamps. Store sessions in Redis or your database, not in client-side storage where they can be extracted. Set session expiration times appropriate to your application's sensitivity—1-7 days for typical SaaS, 15-60 minutes for financial applications.

// Secure session implementation
const crypto = require('crypto');

class SessionService {
  async createSession(userId) {
    const sessionId = crypto.randomBytes(32).toString('hex');
    const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000); // 7 days

    await redis.setex(
      `session:${sessionId}`,
      7 * 24 * 60 * 60, // 7 days in seconds
      JSON.stringify({
        userId,
        createdAt: Date.now(),
        expiresAt: expiresAt.toISOString()
      })
    );

    return { sessionId, expiresAt };
  }

  async validateSession(sessionId) {
    const sessionData = await redis.get(`session:${sessionId}`);

    if (!sessionData) {
      return null; // Session expired or doesn't exist
    }

    const session = JSON.parse(sessionData);

    // Extend session on activity (sliding expiration)
    await redis.expire(`session:${sessionId}`, 7 * 24 * 60 * 60);

    return session;
  }

  async destroySession(sessionId) {
    await redis.del(`session:${sessionId}`);
  }

  async destroyAllUserSessions(userId) {
    // Store user -> sessions mapping for this capability
    const sessionIds = await redis.smembers(`user_sessions:${userId}`);
    const pipeline = redis.pipeline();

    for (const sessionId of sessionIds) {
      pipeline.del(`session:${sessionId}`);
    }

    pipeline.del(`user_sessions:${userId}`);
    await pipeline.exec();
  }
}

Session cookies must use secure flags: HttpOnly prevents JavaScript access (defending against XSS attacks), Secure ensures transmission only over HTTPS, and SameSite=Strict or Lax prevents CSRF attacks. These flags are security fundamentals, not optional enhancements.

// Setting secure cookies
res.cookie('sessionId', sessionId, {
  httpOnly: true,   // No JavaScript access
  secure: true,     // HTTPS only
  sameSite: 'lax',  // CSRF protection
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
  path: '/'
});

Multi-Factor Authentication and Account Recovery

Multi-factor authentication (MFA) is transitioning from enterprise-only to expected by all customers. Implement TOTP (Time-based One-Time Password) using standard libraries—don't build your own cryptography. Support authenticator apps (Google Authenticator, Authy) as the primary MFA method, with SMS backup only if your customer base requires it (SMS is vulnerable to SIM swapping attacks).

// TOTP implementation for MFA
const speakeasy = require('speakeasy');
const qrcode = require('qrcode');

class MFAService {
  async enableMFA(userId) {
    // Generate secret
    const secret = speakeasy.generateSecret({
      name: `YourApp (${userEmail})`,
      length: 32
    });

    // Store secret encrypted in database
    await db.query(
      'UPDATE users SET mfa_secret = $1, mfa_enabled = false WHERE id = $2',
      [await encrypt(secret.base32), userId]
    );

    // Generate QR code for user to scan
    const qrCodeDataURL = await qrcode.toDataURL(secret.otpauth_url);

    return {
      secret: secret.base32,
      qrCode: qrCodeDataURL,
      backupCodes: await this.generateBackupCodes(userId)
    };
  }

  async verifyAndActivateMFA(userId, token) {
    const user = await db.query(
      'SELECT mfa_secret FROM users WHERE id = $1',
      [userId]
    );

    const secret = await decrypt(user.rows[0].mfa_secret);

    const verified = speakeasy.totp.verify({
      secret,
      encoding: 'base32',
      token,
      window: 2 // Allow 2 time steps for clock drift
    });

    if (verified) {
      await db.query(
        'UPDATE users SET mfa_enabled = true WHERE id = $1',
        [userId]
      );
      return { success: true };
    }

    return { success: false, error: 'Invalid code' };
  }

  async verifyMFAToken(userId, token) {
    const user = await db.query(
      'SELECT mfa_secret, mfa_enabled FROM users WHERE id = $1',
      [userId]
    );

    if (!user.rows[0].mfa_enabled) {
      return true; // MFA not enabled, skip check
    }

    const secret = await decrypt(user.rows[0].mfa_secret);

    // Check TOTP token
    const verified = speakeasy.totp.verify({
      secret,
      encoding: 'base32',
      token,
      window: 2
    });

    if (verified) {
      return true;
    }

    // Check backup codes
    return this.verifyBackupCode(userId, token);
  }

  async generateBackupCodes(userId) {
    const codes = [];
    for (let i = 0; i < 10; i++) {
      codes.push(crypto.randomBytes(4).toString('hex'));
    }

    // Store hashed backup codes
    const hashedCodes = await Promise.all(
      codes.map(code => bcrypt.hash(code, 10))
    );

    await db.query(
      'INSERT INTO mfa_backup_codes (user_id, code_hash) VALUES ' +
      hashedCodes.map((_, i) => `($1, $${i + 2})`).join(','),
      [userId, ...hashedCodes]
    );

    return codes; // Return plaintext to user once
  }

  async verifyBackupCode(userId, code) {
    const backupCodes = await db.query(
      'SELECT id, code_hash FROM mfa_backup_codes WHERE user_id = $1 AND used_at IS NULL',
      [userId]
    );

    for (const row of backupCodes.rows) {
      const match = await bcrypt.compare(code, row.code_hash);
      if (match) {
        // Mark code as used
        await db.query(
          'UPDATE mfa_backup_codes SET used_at = NOW() WHERE id = $1',
          [row.id]
        );
        return true;
      }
    }

    return false;
  }
}

Account recovery is security-critical. The standard email-based password reset flow must include: short token expiration (15-60 minutes), single-use tokens, and notification to the account email when a password reset is initiated. Store password reset tokens hashed in the database like passwords—if your database is breached, password reset tokens are as valuable as passwords themselves.

// Secure password reset flow
async function initiatePasswordReset(email) {
  const user = await getUserByEmail(email);

  if (!user) {
    // Don't reveal whether email exists
    return { success: true };
  }

  const resetToken = crypto.randomBytes(32).toString('hex');
  const tokenHash = await bcrypt.hash(resetToken, 10);
  const expiresAt = new Date(Date.now() + 60 * 60 * 1000); // 1 hour

  await db.query(
    'INSERT INTO password_reset_tokens (user_id, token_hash, expires_at) VALUES ($1, $2, $3)',
    [user.id, tokenHash, expiresAt]
  );

  // Send email with reset link
  await emailService.send({
    to: email,
    subject: 'Password Reset Request',
    html: `
      
A password reset was requested for your account.
      
Reset your password
      
This link expires in 1 hour.
      
If you didn't request this, please ignore this email.
    `
  });

  return { success: true };
}

async function resetPassword(token, newPassword) {
  // Find valid token
  const tokens = await db.query(
    'SELECT * FROM password_reset_tokens WHERE expires_at > NOW() AND used_at IS NULL'
  );

  let userId = null;

  for (const row of tokens.rows) {
    const match = await bcrypt.compare(token, row.token_hash);
    if (match) {
      userId = row.user_id;
      await db.query(
        'UPDATE password_reset_tokens SET used_at = NOW() WHERE id = $1',
        [row.id]
      );
      break;
    }
  }

  if (!userId) {
    throw new Error('Invalid or expired reset token');
  }

  // Update password
  const passwordHash = await hashPassword(newPassword);
  await db.query(
    'UPDATE users SET password_hash = $1, updated_at = NOW() WHERE id = $2',
    [passwordHash, userId]
  );

  // Invalidate all existing sessions
  await sessionService.destroyAllUserSessions(userId);

  return { success: true };
}

Rate limiting on authentication endpoints prevents brute force attacks. Limit login attempts to 5 per email per 15 minutes. Limit password reset requests to 3 per email per hour. Return the same response for valid and invalid emails to prevent account enumeration, but apply rate limits regardless to prevent abuse.

Authorization and Multi-Tenant Data Isolation

Authorization bugs are the most common source of data leaks in multi-tenant SaaS. Every database query that returns customer data must filter by the authenticated user's organization. The anti-pattern is checking authorization in some queries but not others, or assuming that knowing a resource ID grants access to it.

The secure pattern adds organization_id to every table that stores customer data and includes it in every query's WHERE clause. Use database-level checks like Row Level Security (RLS) in PostgreSQL as defense in depth, but don't rely on them as your primary authorization mechanism—application-level checks are easier to audit and debug.

// Always filter by organization in queries
// BAD - no organization check
async function getProject(projectId) {
  return db.query('SELECT * FROM projects WHERE id = $1', [projectId]);
}

// GOOD - always filter by organization
async function getProject(projectId, organizationId) {
  return db.query(
    'SELECT * FROM projects WHERE id = $1 AND organization_id = $2',
    [projectId, organizationId]
  );
}

// BETTER - use a base query builder that always adds organization filter
class ProjectService {
  constructor(organizationId) {
    this.organizationId = organizationId;
  }

  async getById(projectId) {
    return db.query(
      'SELECT * FROM projects WHERE id = $1 AND organization_id = $2',
      [projectId, this.organizationId]
    );
  }

  async list(filters = {}) {
    return db.query(
      'SELECT * FROM projects WHERE organization_id = $1 ORDER BY created_at DESC',
      [this.organizationId]
    );
  }
}

API endpoint authorization should happen in middleware that verifies the user has access to the organization and required permissions before controller code executes. This pattern centralizes authorization logic and prevents bypasses where developers forget to add checks.

// Authorization middleware pattern
function requireOrganizationAccess(requiredPermission = null) {
  return async (req, res, next) => {
    const userId = req.user.id;
    const organizationId = req.params.organizationId;

    // Load membership
    const membership = await db.query(
      'SELECT * FROM organization_members WHERE user_id = $1 AND organization_id = $2',
      [userId, organizationId]
    );

    if (!membership.rows[0]) {
      return res.status(403).json({ error: 'Access denied to this organization' });
    }

    req.membership = membership.rows[0];
    req.organizationId = organizationId;

    // Check specific permission if required
    if (requiredPermission) {
      const hasPermission = await permissionService.hasPermission(
        membership.rows[0].role,
        requiredPermission
      );

      if (!hasPermission) {
        return res.status(403).json({
          error: 'Insufficient permissions',
          required: requiredPermission
        });
      }
    }

    next();
  };
}

// Usage in routes
app.get(
  '/api/organizations/:organizationId/projects',
  authenticate,
  requireOrganizationAccess('view_projects'),
  async (req, res) => {
    // Authorization already verified
    const projects = await projectService.list(req.organizationId);
    res.json(projects);
  }
);

Test authorization rigorously. For every API endpoint, write tests that verify: (1) authenticated users can access their own organization's data, (2) authenticated users cannot access other organizations' data, (3) unauthenticated users cannot access any data. These tests catch authorization bypasses that code review might miss.

Input Validation and Injection Prevention

SQL injection remains a top vulnerability despite being solved decades ago. The fix is simple: use parameterized queries exclusively, never string concatenation for SQL. Modern ORMs and database libraries default to parameterized queries, but raw SQL queries require explicit parameterization.

// SQL injection prevention
// DANGEROUS - vulnerable to SQL injection
const userId = req.params.id;
const query = `SELECT * FROM users WHERE id = ${userId}`;
const result = await db.query(query); // Attacker sends: 1 OR 1=1

// SAFE - parameterized query
const userId = req.params.id;
const result = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

Cross-site scripting (XSS) prevention requires output encoding, not input sanitization. Escape HTML entities when rendering user content in HTML contexts. Modern frontend frameworks like React, Vue, and Angular escape by default, but be careful with dangerouslySetInnerHTML or v-html that bypass protection.

// XSS prevention
// DANGEROUS - renders raw HTML


// SAFE - React escapes by default
{userContent}

// If you must render HTML (like rich text), sanitize with DOMPurify
import DOMPurify from 'dompurify';
const cleanHTML = DOMPurify.sanitize(userContent);

Input validation should validate type, format, and range. For email addresses, use regex validation and normalize to lowercase. For numbers, parse and check against expected ranges. For IDs, verify they're UUIDs or integers. Reject invalid input early rather than trying to sanitize it into something valid.

// Input validation middleware
const { body, param, validationResult } = require('express-validator');

app.post('/api/projects',
  authenticate,
  body('name').isString().trim().isLength({ min: 1, max: 255 }),
  body('description').optional().isString().trim().isLength({ max: 5000 }),
  body('budget').optional().isFloat({ min: 0, max: 1000000 }),
  async (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }

    // Validated input is safe to use
    const project = await createProject(req.body);
    res.json(project);
  }
);

File upload security requires validating file types, sizes, and content. Check file extensions and MIME types, but also verify file content matches the claimed type (an attacker can rename a .exe to .jpg). Store uploaded files outside your webroot and serve them through a separate domain or CDN to prevent uploaded JavaScript from executing in your application's context.

Data Encryption and Sensitive Data Protection

Data encryption has two components: encryption in transit (TLS/HTTPS) and encryption at rest (database encryption). HTTPS is non-negotiable for any application handling user data—use Let's Encrypt for free TLS certificates if cost is a concern. Configure TLS to use modern protocols (TLS 1.2+) and strong cipher suites.

Database encryption at rest protects against disk theft or cloud storage breaches. Most cloud databases offer transparent encryption at rest (Amazon RDS, Google Cloud SQL) that encrypts entire databases without application changes. For especially sensitive data like payment information or health records, add application-level encryption for individual fields.

// Field-level encryption for sensitive data
const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const ENCRYPTION_KEY = Buffer.from(process.env.ENCRYPTION_KEY, 'hex'); // 32 bytes

function encrypt(plaintext) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv(ALGORITHM, ENCRYPTION_KEY, iv);

  let encrypted = cipher.update(plaintext, 'utf8', 'hex');
  encrypted += cipher.final('hex');

  const authTag = cipher.getAuthTag();

  // Return iv:authTag:ciphertext
  return `${iv.toString('hex')}:${authTag.toString('hex')}:${encrypted}`;
}

function decrypt(ciphertext) {
  const parts = ciphertext.split(':');
  const iv = Buffer.from(parts[0], 'hex');
  const authTag = Buffer.from(parts[1], 'hex');
  const encrypted = parts[2];

  const decipher = crypto.createDecipheriv(ALGORITHM, ENCRYPTION_KEY, iv);
  decipher.setAuthTag(authTag);

  let decrypted = decipher.update(encrypted, 'hex', 'utf8');
  decrypted += decipher.final('utf8');

  return decrypted;
}

// Usage for PII or payment data
async function storePaymentMethod(userId, cardNumber) {
  const encryptedCard = encrypt(cardNumber);

  await db.query(
    'INSERT INTO payment_methods (user_id, card_number_encrypted) VALUES ($1, $2)',
    [userId, encryptedCard]
  );
}

Key management is critical for encryption security. Store encryption keys in environment variables or dedicated key management services (AWS KMS, Google Cloud KMS), never in your codebase. Rotate encryption keys periodically—implement a versioning system that lets you decrypt old data with old keys while encrypting new data with new keys.

Minimize sensitive data retention. Don't store credit card numbers if you use Stripe or other payment processors that handle tokenization. Don't log passwords, API keys, or tokens. Implement data retention policies that automatically delete old audit logs, session data, and other time-limited information.

Infrastructure Security and Environment Configuration

Infrastructure security starts with secrets management. Never commit API keys, database passwords, or encryption keys to version control. Use environment variables for configuration and secrets management services (AWS Secrets Manager, HashiCorp Vault) for sensitive credentials. Scan repositories for accidentally committed secrets using tools like git-secrets or GitHub secret scanning.

// Secure configuration loading
require('dotenv').config();

// NEVER do this - hardcoded secrets
const config = {
  dbPassword: 'myPassword123',
  stripeKey: 'sk_live_abc123'
};

// DO THIS - environment variables
const config = {
  dbPassword: process.env.DB_PASSWORD,
  stripeKey: process.env.STRIPE_SECRET_KEY,
  encryptionKey: process.env.ENCRYPTION_KEY
};

// Validate required secrets on startup
const requiredEnvVars = [
  'DB_PASSWORD',
  'STRIPE_SECRET_KEY',
  'ENCRYPTION_KEY'
];

for (const envVar of requiredEnvVars) {
  if (!process.env[envVar]) {
    throw new Error(`Missing required environment variable: ${envVar}`);
  }
}

Database security requires multiple layers. Use strong passwords for database users. Limit database access to application servers only—don't expose databases to the public internet. Use read-only database users for read operations and separate credentials for write operations. Enable database audit logging to track all queries and changes.

Container and cloud security follow similar principles. Run containers as non-root users. Scan container images for vulnerabilities using tools like Trivy or Snyk. Keep base images updated with security patches. Use minimal base images (Alpine Linux) to reduce attack surface. For cloud infrastructure, enable CloudTrail (AWS) or Cloud Audit Logs (GCP) to track all API calls and configuration changes.

# Dockerfile security best practices
FROM node:18-alpine AS builder

# Run as non-root user
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nodejs -u 1001

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

USER nodejs

EXPOSE 3000

CMD ["node", "server.js"]

Security Monitoring and Incident Response

Security monitoring detects attacks and breaches in progress. Log authentication events (login attempts, password resets, MFA changes), authorization failures (access denied responses), and sensitive actions (data exports, user deletions, permission changes). Send logs to a centralized logging service (Datadog, New Relic, CloudWatch) rather than storing them only on application servers.

// Security event logging
class SecurityLogger {
  async logAuthEvent(event, details) {
    const logEntry = {
      timestamp: new Date().toISOString(),
      event,
      userId: details.userId || null,
      email: details.email || null,
      ip: details.ip,
      userAgent: details.userAgent,
      success: details.success,
      reason: details.reason || null
    };

    // Log to application logs
    console.log('[SECURITY]', JSON.stringify(logEntry));

    // Store in database for analysis
    await db.query(
      'INSERT INTO security_events (event, user_id, ip, success, details) VALUES ($1, $2, $3, $4, $5)',
      [event, details.userId, details.ip, details.success, JSON.stringify(logEntry)]
    );

    // Alert on suspicious patterns
    if (event === 'login_failed') {
      await this.checkForBruteForce(details.email, details.ip);
    }
  }

  async checkForBruteForce(email, ip) {
    const recentFailures = await db.query(
      'SELECT COUNT(*) FROM security_events WHERE event = $1 AND (email = $2 OR ip = $3) AND created_at > NOW() - INTERVAL \'15 minutes\'',
      ['login_failed', email, ip]
    );

    const failureCount = parseInt(recentFailures.rows[0].count);

    if (failureCount >= 5) {
      await this.sendAlert({
        severity: 'high',
        title: 'Possible brute force attack',
        message: `${failureCount} failed login attempts for ${email} from ${ip} in last 15 minutes`
      });
    }
  }
}

Automated alerting catches attacks in progress. Alert on: multiple failed login attempts from the same IP, successful logins from new geographic locations, privilege escalation (users gaining admin roles), unusual data export volumes, and API rate limit violations. Use tiered alerting—high-severity alerts page on-call engineers, medium-severity alerts post to Slack, low-severity alerts generate daily digest emails.

Incident response planning prepares you for inevitable security incidents. Document procedures for: detecting breaches, isolating compromised systems, notifying affected users, and restoring services. Store this documentation outside your application infrastructure (it's useless if the breach takes down your documentation too). Practice incident response through tabletop exercises or simulated breaches.

// Incident response checklist (store in runbook)
/*
1. DETECTION & ASSESSMENT (0-15 minutes)
   - Identify breach source and scope
   - Determine what data was accessed
   - Check audit logs for attacker actions

2. CONTAINMENT (15-60 minutes)
   - Rotate compromised credentials immediately
   - Block attacker IP addresses
   - Disable compromised user accounts
   - Deploy patches if vulnerability identified

3. ERADICATION (1-4 hours)
   - Remove attacker access completely
   - Scan for backdoors or persistent access
   - Verify all systems are clean

4. RECOVERY (4-24 hours)
   - Restore services incrementally
   - Monitor for re-compromise attempts
   - Verify security controls are functioning

5. POST-INCIDENT (24-72 hours)
   - Notify affected users (legal requirement in many jurisdictions)
   - File required regulatory reports
   - Conduct post-mortem
   - Implement preventive measures
*/

Compliance Readiness: SOC 2 and GDPR Foundations

SOC 2 certification is increasingly required for B2B SaaS selling to enterprise customers. SOC 2 Type II audits verify your security controls over a 6-12 month period. Preparation requires: documented security policies, access control lists, change management processes, vendor security assessments, and comprehensive audit logging. Start these practices early—you can't retroactively create 6 months of audit logs when an enterprise customer requests SOC 2 compliance.

GDPR compliance (for European customers) requires: legitimate basis for data processing, ability to export user data, ability to delete user data, data processing agreements with subprocessors, and breach notification procedures. Implement these capabilities regardless of your current customer base—they're good practices that build trust with all customers.

// GDPR data export implementation
async function exportUserData(userId) {
  // Collect all user data from various tables
  const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
  const projects = await db.query('SELECT * FROM projects WHERE user_id = $1', [userId]);
  const organizations = await db.query(
    'SELECT o.* FROM organizations o JOIN organization_members om ON o.id = om.organization_id WHERE om.user_id = $1',
    [userId]
  );

  const userData = {
    personal_information: user.rows[0],
    projects: projects.rows,
    organizations: organizations.rows,
    exported_at: new Date().toISOString()
  };

  // Return as JSON (or CSV, or both)
  return userData;
}

// GDPR data deletion implementation
async function deleteUserData(userId, deleteReason) {
  await db.query('BEGIN');

  try {
    // Log deletion request (GDPR requires retention of deletion logs)
    await db.query(
      'INSERT INTO user_deletion_log (user_id, requested_at, reason) VALUES ($1, NOW(), $2)',
      [userId, deleteReason]
    );

    // Anonymize or delete user data
    await db.query(
      'UPDATE users SET email = $1, name = $2, deleted_at = NOW() WHERE id = $3',
      [`deleted_${userId}@example.com`, 'Deleted User', userId]
    );

    // Remove from organizations
    await db.query('DELETE FROM organization_members WHERE user_id = $1', [userId]);

    // Transfer or delete user-created content based on your policy
    await db.query(
      'UPDATE projects SET user_id = NULL WHERE user_id = $1',
      [userId]
    );

    await db.query('COMMIT');
  } catch (error) {
    await db.query('ROLLBACK');
    throw error;
  }
}

Privacy by design means building privacy into features from the start. Default to minimal data collection—don't ask for phone numbers if you don't need them. Provide granular consent options for optional data uses. Make privacy controls easy to find and use. These practices satisfy GDPR requirements while improving overall product quality.

Dependency Security and Supply Chain

Modern applications depend on hundreds of npm packages, Python libraries, or other third-party code. Each dependency is a potential security vulnerability. Use automated tools (npm audit, Snyk, Dependabot) to scan dependencies for known vulnerabilities. Update dependencies regularly—monthly dependency updates prevent accumulating years of security debt.

# Check for vulnerabilities
npm audit

# Update to fix vulnerabilities
npm audit fix

# For vulnerabilities requiring breaking changes
npm audit fix --force

# Add to CI/CD pipeline
# .github/workflows/security.yml
name: Security Audit
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
      - run: npm ci
      - run: npm audit --audit-level=moderate

Vendor security assessments apply to your third-party services (payment processors, email providers, analytics tools). Each vendor you integrate processes your customer data and represents a security risk. Review vendor security practices: do they have SOC 2? Do they encrypt data? What's their breach notification process? Document these assessments—enterprise customers will ask about your subprocessors.

Lock dependency versions in production. Use package-lock.json (npm), Pipfile.lock (Python), or Gemfile.lock (Ruby) to ensure identical dependencies between development and production. This prevents supply chain attacks where attackers compromise packages after you've tested them, and the next deploy pulls malicious code.

Frequently Asked Questions

When should I hire a security engineer?

Most startups should hire a dedicated security engineer around 20-30 total engineers or when closing enterprise deals requiring SOC 2 compliance. Before that, one engineer should own security as 20-30% of their role. Use external security consultants for penetration testing and compliance audits rather than hiring full-time security staff at early stages.

How often should I conduct penetration testing?

Annual penetration testing is the standard for B2B SaaS. Schedule tests after major feature launches or architecture changes. Budget $10,000-$30,000 for thorough penetration tests by reputable firms. Use automated vulnerability scanning (like OWASP ZAP) between manual tests to catch obvious issues quickly.

Do I need SOC 2 compliance to sell to enterprises?

Not all enterprises require SOC 2, but it's increasingly common. Expect 30-50% of enterprise sales cycles to request SOC 2 reports. You can close some enterprise deals without it by completing security questionnaires and agreeing to contractual security commitments, but SOC 2 significantly shortens sales cycles by providing standardized compliance evidence.

How do I handle security vulnerabilities reported by users?

Create a [email protected] email and document your vulnerability disclosure policy. Respond to reports within 24 hours acknowledging receipt. Provide status updates as you investigate. Fix confirmed vulnerabilities within 90 days (sooner for critical issues). Consider a bug bounty program once you're established—platforms like HackerOne and Bugcrowd manage these programs.

Should I encrypt my entire database?

Most cloud databases offer transparent encryption at rest enabled by default—use it. For especially sensitive fields (payment data, health information), add application-level encryption. Don't encrypt everything at application level—it prevents database features like indexing and searching from working on encrypted fields. Encrypt based on sensitivity, not blanket policies.

What's the minimum viable security for launching a SaaS product?

Minimum viable security includes: HTTPS everywhere, secure password hashing (bcrypt), parameterized SQL queries, authentication on all non-public endpoints, authorization checks filtering by organization, session management with secure cookies, input validation, and basic security logging. These are non-negotiable regardless of company size or customer type.

How do I balance security and development velocity?

Build security into development processes rather than adding it afterward. Use secure defaults: ORMs that parameterize queries, frameworks that escape output, authentication libraries rather than custom implementations. Automate security checks in CI/CD: dependency scanning, static analysis, automated testing. Most security best practices add negligible development time when built in from the start.

What security training should developers receive?

All developers should complete OWASP Top 10 training understanding common vulnerabilities. Backend developers need SQL injection, authentication, and authorization training. Frontend developers need XSS and CSRF training. Run annual security training and update it with lessons from your own incidents or penetration test findings. Hands-on training (like intentionally vulnerable practice apps) is more effective than lecture-based training.

Conclusion

Security is not a feature you add later—it's a foundation you build from the start. The foundational security practices in this article—secure authentication, proper authorization, input validation, data encryption, and security logging—prevent the vast majority of vulnerabilities that appear in penetration tests and cause breaches. Implement these patterns before launch, not when your first enterprise customer requests a security review.

Security requirements grow with your business. Early-stage startups need the basics: HTTPS, password hashing, and SQL injection prevention. Growth-stage companies need MFA, comprehensive audit logging, and documented security policies. Enterprise-focused companies need SOC 2 compliance, penetration testing, and incident response procedures. Each tier builds on the previous one—you can't skip foundational security to rush toward compliance certifications.

The cost of security is measured in thousands of dollars and weeks of engineering time. The cost of security breaches is measured in millions of dollars, years of reputation damage, and potentially business failure. Every hour invested in security infrastructure is insurance against catastrophic downside that affects not just your company but your customers' trust in SaaS products generally. Build security in from day one, maintain it continuously, and treat it as a competitive advantage rather than a cost center.