This guide provides information and practical guidance for ensuring compliance with relevant security regulations, standards, and frameworks. It helps teams navigate compliance requirements as part of the Definition of Done.

The purpose of this guide is to:

• Clarify compliance requirements for different project types
• Provide implementation guidance for compliance controls
• Map regulatory requirements to security controls
• Streamline the compliance process
• Reduce compliance overhead through standardization

This section outlines the key compliance frameworks relevant to our organization.

Applicability: Projects handling personal data of EU residents

Key Requirements:

• Data Protection by Design and Default

  • Implement appropriate technical and organizational measures
  • Ensure data minimization
  • Process only data necessary for each specific purpose

• Lawful Basis for Processing

  • Identify and document lawful basis
  • Obtain and manage consent when required
  • Implement mechanisms to withdraw consent

• Data Subject Rights

  • Right to access
  • Right to rectification
  • Right to erasure (right to be forgotten)
  • Right to restrict processing
  • Right to data portability
  • Right to object to processing

• Security Measures

  • Pseudonymization and encryption
  • Confidentiality, integrity, availability, and resilience
  • Regular testing and evaluation of security measures
  • Breach notification capabilities

• Data Processing Records

  • Maintain records of processing activities
  • Document purpose, categories, transfers, and security measures

Applicability: Projects handling credit card data

Key Requirements:

• Secure Network and Systems

  • Install and maintain firewall configuration
  • Change vendor-supplied defaults

• Protect Cardholder Data

  • Protect stored data
  • Encrypt transmission of cardholder data

• Vulnerability Management

  • Use and regularly update anti-virus
  • Develop and maintain secure systems and applications

• Access Control Measures

  • Restrict access to cardholder data
  • Unique ID for each person with computer access
  • Restrict physical access to cardholder data

• Network Monitoring and Testing

  • Track and monitor all access to network resources
  • Regularly test security systems and processes

• Information Security Policy

  • Maintain a policy addressing information security

Applicability: Projects handling protected health information

Key Requirements:

• Privacy Rule

  • Limit uses and disclosures of PHI
  • Provide privacy notices
  • Allow for individual rights over PHI

• Security Rule

  • Administrative safeguards
  • Physical safeguards
  • Technical safeguards

• Breach Notification Rule

  • Notification to affected individuals
  • Notification to the Secretary of HHS
  • Notification to the media in certain circumstances

Applicability: Cloud service providers and organizations handling customer data

Key Requirements (based on the Trust Services Criteria):

• Security

  • Protection against unauthorized access
  • Prevention, detection, and response to security threats

• Availability

  • System availability for operation and use
  • Backup and disaster recovery mechanisms

• Processing Integrity

  • System processing is complete, accurate, timely, and authorized

• Confidentiality

  • Protection of confidential information
  • Access controls and encryption

• Privacy

  • Collection, use, retention, and disposal of personal information
  • Disclosure and notification

This section maps common compliance requirements to specific security controls in our Definition of Done.

This section provides practical guidance for implementing compliance requirements.

1. Identify Personal Data

   • Document what personal data is collected
   • Where it is stored
   • How it is processed
   • Legal basis for processing
   • Retention period

2. Data Flow Diagram

   • Create visual representation of data flows
   • Identify cross-border transfers
   • Document data processors

3. Implementation Example: Data Inventory Template

Data Category: Customer Account Information
- Data Elements: Name, Email, Address, Phone
- Purpose: Order Processing, Customer Support
- Legal Basis: Contract Performance
- Storage Location: Customer Database
- Retention Period: 7 years after last purchase
- Access Controls: Role-based access for Customer Service team
- Cross-Border Transfers: None

1. Access Request Handling

   • Create API endpoints for data export
   • Implement authentication for requestors
   • Include all relevant data categories
   • Provide in machine-readable format

2. Deletion Request Handling

   • Implement "soft delete" functionality
   • Address cascading deletes
   • Handle backup data
   • Document exceptions for legal requirements

3. Implementation Example: Right to Erasure API Endpoint

// Node.js example
app.delete('/api/users/:userId/data', authenticate, async (req, res) => {
  try {
    // Verify the requester is authorized
    if (req.user.id !== req.params.userId && !req.user.isAdmin) {
      return res.status(403).json({ error: 'Unauthorized' });
    }
    
    // Perform soft delete in primary database
    await User.softDelete(req.params.userId);
    
    // Log deletion request for backup cleanup
    await DeletionQueue.add({
      userId: req.params.userId,
      requestDate: new Date(),
      requestedBy: req.user.id
    });
    
    // Schedule deletion from analytics systems
    await scheduleDeletionFromAnalytics(req.params.userId);
    
    // Record compliance activity
    await ComplianceLog.create({
      activity: 'DATA_DELETION',
      subjectId: req.params.userId,
      requestedBy: req.user.id,
      timestamp: new Date()
    });
    
    return res.status(200).json({ 
      message: 'Deletion request received and processing initiated',
      reference: deletionReference
    });
  } catch (error) {
    return res.status(500).json({ error: 'Deletion request failed' });
  }
});

1. Network Segmentation

   • Implement firewalls between CDE and other networks
   • Use network segmentation to isolate payment processing
   • Implement strict access controls to CDE

2. Data Flow Minimization

   • Map all cardholder data flows
   • Minimize systems that process cardholder data
   • Use tokenization to reduce scope

3. Implementation Example: Network Segmentation

# Firewall configuration example
# Allow only necessary traffic to payment processing subnet

# Define the payment processing subnet
define PAYMENT_SUBNET 10.10.20.0/24

# Allow only specific services
iptables -A FORWARD -p tcp -d $PAYMENT_SUBNET --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp -s $PAYMENT_SUBNET --sport 443 -m state --state ESTABLISHED -j ACCEPT

# Allow specific management traffic
iptables -A FORWARD -p tcp -s $ADMIN_SUBNET -d $PAYMENT_SUBNET --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

# Log and drop all other traffic
iptables -A FORWARD -d $PAYMENT_SUBNET -j LOG --log-prefix "PAYMENT-DENIED: "
iptables -A FORWARD -d $PAYMENT_SUBNET -j DROP

1. Use Tokenization or Third-Party Processing

   • Outsource payment processing to PCI-compliant provider
   • Use hosted payment pages when possible
   • Implement tokenization to avoid storing card data

2. Secure Transmission

   • Use TLS 1.2+ for all payment data transmission
   • Validate certificates
   • Implement perfect forward secrecy

3. Implementation Example: Stripe Integration

// React component example using Stripe Elements
import {CardElement, useStripe, useElements} from '@stripe/react-stripe-js';

const CheckoutForm = () => {
  const stripe = useStripe();
  const elements = useElements();

  const handleSubmit = async (event) => {
    event.preventDefault();
    
    // Create payment method without storing card details in your system
    const {error, paymentMethod} = await stripe.createPaymentMethod({
      type: 'card',
      card: elements.getElement(CardElement),
    });

    if (!error) {
      // Send payment method ID to server
      const response = await fetch('/api/process-payment', {
        method: 'POST',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify({
          payment_method_id: paymentMethod.id,
          amount: 1000,  // $10.00
          currency: 'usd',
        }),
      });
      
      // Handle server response
      const result = await response.json();
      
      if (result.requires_action) {
        // Handle 3D Secure authentication if required
        const {error, paymentIntent} = await stripe.handleCardAction(
          result.payment_intent_client_secret
        );
        // Complete payment after 3D Secure
        if (!error) {
          await fetch('/api/complete-payment', {
            method: 'POST',
            headers: {'Content-Type': 'application/json'},
            body: JSON.stringify({
              payment_intent_id: paymentIntent.id
            }),
          });
        }
      }
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <CardElement />
      <button type="submit" disabled={!stripe}>Pay</button>
    </form>
  );
};

1. Role-Based Access

   • Define roles with minimum necessary access
   • Implement access control lists
   • Require approval for role changes

2. Access Logging and Monitoring

   • Log all access to PHI
   • Implement alerting for unusual access patterns
   • Conduct regular access reviews

3. Implementation Example: PHI Access Logging

-- SQL Schema for PHI access logging
CREATE TABLE phi_access_logs (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    patient_id INTEGER NOT NULL REFERENCES patients(id),
    record_type VARCHAR(50) NOT NULL,
    action_type VARCHAR(20) NOT NULL, -- 'VIEW', 'UPDATE', 'DELETE'
    access_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    access_reason VARCHAR(200),
    source_ip VARCHAR(45),
    session_id VARCHAR(100)
);

-- Trigger function to log PHI access
CREATE OR REPLACE FUNCTION log_phi_access()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO phi_access_logs (
        user_id, patient_id, record_type, action_type, 
        access_reason, source_ip, session_id
    )
    VALUES (
        current_setting('app.current_user_id')::INTEGER,
        NEW.patient_id,
        TG_TABLE_NAME,
        CASE
            WHEN TG_OP = 'INSERT' THEN 'CREATE'
            WHEN TG_OP = 'UPDATE' THEN 'UPDATE'
            WHEN TG_OP = 'DELETE' THEN 'DELETE'
        END,
        current_setting('app.access_reason', true),
        current_setting('app.source_ip', true),
        current_setting('app.session_id', true)
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Apply trigger to tables containing PHI
CREATE TRIGGER log_patient_access
AFTER INSERT OR UPDATE OR DELETE ON patient_records
FOR EACH ROW EXECUTE FUNCTION log_phi_access();

1. Encrypted Messaging

   • Implement end-to-end encryption for messages
   • Secure all APIs transmitting PHI
   • Implement secure email for PHI sharing

2. Implementation Example: Secure Messaging System

// Java example for encrypted messaging
public class SecureMessage {
    private static final String ALGORITHM = "AES/GCM/NoPadding";
    private static final int TAG_LENGTH_BIT = 128;
    private static final int IV_LENGTH_BYTE = 12;
    
    public static byte[] encrypt(byte[] plaintext, SecretKey key) throws Exception {
        // Generate random IV
        byte[] iv = new byte[IV_LENGTH_BYTE];
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);
        
        // Create cipher instance
        final Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec spec = new GCMParameterSpec(TAG_LENGTH_BIT, iv);
        cipher.init(Cipher.ENCRYPT_MODE, key, spec);
        
        // Add message metadata
        cipher.updateAAD(getMessageMetadata());
        
        // Encrypt
        byte[] ciphertext = cipher.doFinal(plaintext);
        
        // Combine IV and ciphertext
        ByteBuffer byteBuffer = ByteBuffer.allocate(iv.length + ciphertext.length);
        byteBuffer.put(iv);
        byteBuffer.put(ciphertext);
        
        // Log the secure transmission (without content)
        logSecureMessageTransmission(getRecipientId());
        
        return byteBuffer.array();
    }
    
    public static byte[] decrypt(byte[] cipherMessage, SecretKey key) throws Exception {
        // Extract IV
        ByteBuffer byteBuffer = ByteBuffer.wrap(cipherMessage);
        byte[] iv = new byte[IV_LENGTH_BYTE];
        byteBuffer.get(iv);
        
        // Extract ciphertext
        byte[] ciphertext = new byte[byteBuffer.remaining()];
        byteBuffer.get(ciphertext);
        
        // Create cipher instance
        final Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec spec = new GCMParameterSpec(TAG_LENGTH_BIT, iv);
        cipher.init(Cipher.DECRYPT_MODE, key, spec);
        
        // Add message metadata for authentication
        cipher.updateAAD(getMessageMetadata());
        
        // Decrypt
        byte[] plaintext = cipher.doFinal(ciphertext);
        
        // Log the access to PHI
        logPhiAccess(getSenderId(), "MESSAGE", "VIEW");
        
        return plaintext;
    }
}

1. Formal Change Process

   • Document change management procedure
   • Require change approval
   • Test changes before implementation
   • Maintain change log

2. Implementation Example: Change Management Workflow

# CI/CD Pipeline with Change Management Controls (GitLab CI example)
stages:
  - validate
  - build
  - test
  - security_scan
  - approve
  - deploy

validate_change:
  stage: validate
  script:
    - ./scripts/validate-change-request.sh
    - ./scripts/check-change-approval.sh
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

build:
  stage: build
  script:
    - ./scripts/build-application.sh
  artifacts:
    paths:
      - build/

test:
  stage: test
  script:
    - ./scripts/run-test-suite.sh
  dependencies:
    - build

security_scan:
  stage: security_scan
  script:
    - ./scripts/run-security-scans.sh
  dependencies:
    - build
  artifacts:
    paths:
      - reports/

change_approval:
  stage: approve
  script:
    - ./scripts/record-approval.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH =~ /^release-/'
  when: manual
  allow_failure: false

deploy_production:
  stage: deploy
  script:
    - ./scripts/deploy-to-production.sh
    - ./scripts/record-change-log.sh
  environment:
    name: production
  dependencies:
    - build
    - security_scan
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  when: manual

1. Regular Access Reviews

   • Conduct quarterly access reviews
   • Document review results
   • Remove unnecessary access
   • Update access based on job changes

2. Implementation Example: Access Review Process

# Python example for access review system
def generate_access_review(department_id=None):
    """Generate access review for all users or specific department"""
    
    # Get users to review
    if department_id:
        users = get_department_users(department_id)
    else:
        users = get_all_users()
    
    # Create review tasks
    review_id = create_access_review_record()
    
    for user in users:
        # Get user's access rights
        access_rights = get_user_access(user.id)
        
        # Get manager for review assignment
        manager = get_user_manager(user.id)
        
        # Create review task
        create_review_task(
            review_id=review_id,
            user_id=user.id,
            reviewer_id=manager.id,
            access_rights=access_rights,
            due_date=datetime.now() + timedelta(days=14)
        )
        
        # Send notification
        send_review_notification(manager.email, user.name, review_id)
    
    # Log compliance activity
    log_compliance_activity(
        activity_type="ACCESS_REVIEW_INITIATED",
        details=f"Access review {review_id} initiated for {len(users)} users"
    )
    
    return review_id

def process_review_response(review_task_id, approvals, revocations, comments):
    """Process manager's review response"""
    
    # Update review task status
    update_review_task_status(review_task_id, "COMPLETED")
    
    # Process approved access
    for access_id in approvals:
        update_access_review_result(access_id, "APPROVED")
    
    # Process revoked access
    for access_id in revocations:
        # Remove access
        revoke_user_access(access_id)
        
        # Update review result
        update_access_review_result(access_id, "REVOKED")
        
        # Create ticket for access removal
        create_access_removal_ticket(access_id)
    
    # Add review comments
    add_review_comments(review_task_id, comments)
    
    # Check if review is complete
    check_review_completion(get_review_id_for_task(review_task_id))

This section provides templates for documenting compliance activities.

# Compliance Assessment Report

## Project Information
- Project Name: [Project Name]
- Assessment Date: [YYYY-MM-DD]
- Assessor: [Name]

## Applicable Regulations
- [x] GDPR
- [ ] PCI DSS
- [ ] HIPAA
- [x] SOC 2

## Assessment Summary
[Brief summary of compliance assessment results]

## Compliance Requirements

### Requirement 1: [Requirement Name]
- Status: [Compliant/Partially Compliant/Non-Compliant]
- Implementation Details: [Description of implementation]
- Evidence: [Links to evidence]
- Gaps: [Description of any gaps]
- Remediation Plan: [Plan to address gaps]

### Requirement 2: [Requirement Name]
...

## Conclusion
[Overall compliance assessment conclusion]

## Approval
- Security Approver: [Name]
- Approval Date: [YYYY-MM-DD]

# Data Processing Inventory

## Data Category: [Category Name]

### Data Elements
- [List of data elements in this category]

### Processing Details
- Purpose: [Purpose of processing]
- Legal Basis: [Legal basis for processing]
- Storage Location: [Where data is stored]
- Retention Period: [How long data is kept]
- Access Controls: [Who can access the data]

### Data Flows
- Collection: [How data is collected]
- Processing: [How data is processed]
- Sharing: [External parties data is shared with]
- Cross-Border Transfers: [Countries data is transferred to]

### Security Controls
- Encryption: [Encryption measures]
- Access Controls: [Access control measures]
- Monitoring: [Monitoring measures]

# Security Incident Response Report

## Incident Information
- Incident ID: [ID]
- Date Discovered: [YYYY-MM-DD]
- Date Contained: [YYYY-MM-DD]
- Date Resolved: [YYYY-MM-DD]
- Incident Type: [Type]
- Severity: [Critical/High/Medium/Low]

## Incident Details
- Description: [Description of the incident]
- Affected Systems: [Systems impacted]
- Affected Data: [Data impacted]
- Root Cause: [Determined root cause]

## Response Actions
- Initial Response: [Initial actions taken]
- Containment: [Containment actions]
- Eradication: [Eradication actions]
- Recovery: [Recovery actions]

## Compliance Implications
- Reportable Breach: [Yes/No]
- Regulations Affected: [List of regulations]
- Reporting Timeline: [Required reporting timeline]
- External Notifications: [Parties notified]

## Lessons Learned
- What Worked Well: [Positive aspects]
- Areas for Improvement: [Improvement opportunities]
- Preventive Measures: [New measures implemented]

## Approval
- Security Officer: [Name]
- Privacy Officer: [Name]
- Legal Review: [Name]

• EU General Data Protection Regulation (GDPR)
• PCI Security Standards Council
• HHS HIPAA Guidance
• AICPA SOC 2 Guidance
• NIST Cybersecurity Framework
• ISO/IEC 27001

• Security Standards
• Security Implementation Guide
• Security Best Practices
• Data Protection