Skip to content

Compliance Guide: GDPR, HIPAA, PCI-DSS

Version: 1.0.0
Last Updated: January 15, 2026
Disclaimer: This guide provides technical features to support compliance. Consult legal counsel for compliance certification.

Introduction

USL includes features designed to help organizations meet regulatory requirements. This document maps USL features to common compliance frameworks:

  • GDPR (General Data Protection Regulation)
  • HIPAA (Health Insurance Portability and Accountability Act)
  • PCI-DSS (Payment Card Industry Data Security Standard)

Important: USL provides tools for compliance, but does not guarantee compliance. Organizations must implement proper processes, policies, and controls beyond the compiler.

GDPR Compliance

Overview

GDPR regulates personal data processing for EU residents. Key requirements: - Data minimization: Collect only necessary data - Purpose limitation: Use data only for stated purposes - Storage limitation: Delete data when no longer needed - Consent management: Obtain and track user consent - Right to access: Users can view their data - Right to erasure: Users can delete their data - Right to portability: Users can export their data - Data breach notification: Report breaches within 72 hours

USL Features for GDPR

1. Data Minimization (Art. 5.1.c)

Requirement: Collect only data that is adequate, relevant, and limited to what is necessary.

USL Support: - Explicit field definitions: Only declared fields are stored - No implicit data collection: Compiler enforces explicit declarations - Optional fields: field: Type? for non-required data

Example: 

entity User {
  // Required fields only
  id: String
  email: String

  // Optional personal data
  fullName: String?
  dateOfBirth: Date?
  phoneNumber: String?

  // NOT included: Unnecessary fields like IP address, browser fingerprint
}

Verification: Schema review ensures only necessary fields exist.

2. Purpose Limitation (Art. 5.1.b)

Requirement: Data collected for specific purposes; not used for incompatible purposes.

USL Support: - Policy-based access: authorize statements document purposes - Behavior documentation: Purpose declared in behavior definitions - Audit trail: Policy checks logged

Example: 

// Purpose: User authentication
policy CanAuthenticateUser(user: User, credentials: Credentials) {
  // ...
}

// Purpose: Order fulfillment
policy CanProcessOrder(user: User, order: Order) {
  // ...
}

// ❌ Cannot use authentication data for marketing without separate policy

Verification: Policy audit ensures purposes are properly scoped.

3. Right to Access (Art. 15)

Requirement: Users can obtain confirmation of data processing and access their personal data.

USL Support: - Generated API endpoints: Automatic /users/{id} endpoint - Policy enforcement: Users can access their own data - Complete data export: All user fields included

Example: 

policy CanReadOwnData(actor: User, target: User) {
  actor.id == target.id
}

behavior GetMyData(actor: User) -> User {
  authorize CanReadOwnData(actor, actor)
  expose Read[User]
}

Generated API: 

GET /api/users/me
Authorization: Bearer <token>

Response: {
  "id": "123",
  "email": "user@example.com",
  "fullName": "John Doe",
  "createdAt": "2026-01-01T00:00:00Z"
}

4. Right to Erasure (Art. 17)

Requirement: Users can request deletion of their personal data.

USL Support: - Generated DELETE endpoints: Automatic deletion behavior - Cascade deletes: Related data automatically deleted - Anonymization option: Replace deletion with anonymization

Example: 

behavior DeleteMyAccount(actor: User) {
  authorize CanDeleteOwnAccount(actor)
  expose Delete[User]

  // Cascade delete related data
  actor.posts.forEach(post => delete post)
  actor.comments.forEach(comment => delete comment)

  delete actor
}

Generated API: 

DELETE /api/users/me
Authorization: Bearer <token>

Response: 204 No Content

Anonymization Alternative: 

behavior AnonymizeAccount(actor: User) {
  authorize CanAnonymizeAccount(actor)

  actor.email = "deleted-" + actor.id + "@example.com"
  actor.fullName = "[Deleted User]"
  actor.phoneNumber = null
  actor.deletedAt = now()
}

5. Right to Data Portability (Art. 20)

Requirement: Users can receive their data in a structured, commonly used, machine-readable format.

USL Support: - JSON export: Generated API returns JSON - Complete data: All user fields included - Standard format: JSON complies with portability requirements

Example: 

behavior ExportMyData(actor: User) -> UserExport {
  authorize CanExportOwnData(actor)

  return UserExport {
    user: actor,
    posts: actor.posts.all(),
    comments: actor.comments.all(),
    metadata: ExportMetadata {
      exportedAt: now(),
      format: "JSON",
      version: "1.0"
    }
  }
}

Generated API: 

GET /api/users/me/export
Authorization: Bearer <token>

Response: {
  "user": { ... },
  "posts": [ ... ],
  "comments": [ ... ],
  "metadata": {
    "exportedAt": "2026-01-15T10:00:00Z",
    "format": "JSON",
    "version": "1.0"
  }
}

Requirement: Obtain explicit consent for data processing; allow withdrawal.

USL Support: - Consent entity: Model consent as first-class entity - Policy-based processing: Require consent for behaviors - Consent audit trail: Track consent changes

Example: 

entity Consent {
  userId: String
  purpose: String  // "marketing", "analytics", etc.
  granted: Bool
  grantedAt: DateTime?
  revokedAt: DateTime?
}

policy HasConsent(user: User, purpose: String) {
  user.consents.any(c => 
    c.purpose == purpose && 
    c.granted == true &&
    c.revokedAt == null
  )
}

behavior SendMarketingEmail(user: User, content: EmailContent) {
  authorize HasConsent(user, "marketing")
  expose IO[Email]
  EmailService.send(user.email, content)
}

Generated API: 

POST /api/consents
{
  "purpose": "marketing",
  "granted": true
}

DELETE /api/consents/marketing

7. Data Breach Notification (Art. 33, 34)

Requirement: Report breaches to supervisory authority within 72 hours; notify affected individuals if high risk.

USL Support: - Audit logging: All data access logged - Anomaly detection: Unusual access patterns logged - Incident response: Generated monitoring infrastructure

Example (monitoring configuration): 

# Generated monitoring/alerts.yaml
alerts:
  - name: UnusualDataAccess
    condition: access_count > 1000 in 1h
    severity: high
    notify: security-team@example.com

  - name: UnauthorizedAccess
    condition: http_status == 403
    threshold: 10 in 5m
    severity: critical
    notify: security-team@example.com

Manual Process Required: USL provides monitoring; organization must implement notification procedures.

8. Data Protection by Design and Default (Art. 25)

Requirement: Implement appropriate technical and organizational measures to protect data.

USL Support: - Secret types: Secret<Encrypted> for PII - Policy enforcement: Default-deny access control - Minimal data exposure: Only necessary fields in APIs - Secure defaults: TLS, secure headers, etc.

Example: 

entity User {
  id: String
  email: String
  fullName: Secret<Encrypted>  // PII encrypted at rest
  ssn: Secret<Encrypted>        // Highly sensitive PII
}

export entity User {
  expose [id, email]  // Only non-sensitive fields exposed by default
  hide [fullName, ssn]  // PII not exposed
}

GDPR Compliance Checklist

Requirement USL Support Manual Steps Required
Data minimization ✅ Explicit fields Review schema quarterly
Purpose limitation ✅ Policy-based access Document purposes
Right to access ✅ Generated APIs None
Right to erasure ✅ Generated DELETE Test deletion process
Right to portability ✅ JSON export None
Consent management ✅ Consent entity Implement UI flows
Breach notification ⚠️ Monitoring only Create incident response plan
Data protection by design ✅ Security features Regular security audits
Data processing agreements ❌ Not provided Legal counsel
Privacy policy ❌ Not provided Legal counsel

HIPAA Compliance

Overview

HIPAA regulates Protected Health Information (PHI) in the US. Key requirements: - Access controls: Only authorized users access PHI - Audit logging: Track all PHI access - Encryption: PHI encrypted at rest and in transit - Data integrity: Prevent unauthorized PHI modification - Authentication: Verify user identity - Transmission security: Secure PHI transmission

USL Features for HIPAA

1. Access Controls (§164.308(a)(4))

Requirement: Implement policies to ensure authorized access to PHI.

USL Support: - Policy enforcement: authorize statements for all PHI access - Role-based access: User roles enforced in policies - Least privilege: Default-deny access control

Example: 

entity Patient {
  id: String
  name: String
  medicalRecordNumber: String
  diagnoses: List<Diagnosis>
  medications: List<Medication>
}

policy CanAccessPatientRecord(actor: User, patient: Patient) {
  actor.role == "doctor" && actor.patients.contains(patient) ||
  actor.role == "nurse" && actor.assignedPatients.contains(patient) ||
  actor.id == patient.userId  // Patient can access own record
}

behavior GetPatientRecord(actor: User, patientId: String) -> Patient {
  let patient = Patient.findById(patientId)
  authorize CanAccessPatientRecord(actor, patient)
  expose Read[Patient]
}

2. Audit Controls (§164.308(a)(1)(ii)(D))

Requirement: Implement hardware, software, and procedural mechanisms to record and examine PHI activity.

USL Support: - Generated audit logging: All PHI access logged automatically - Immutable logs: Write-only audit trail - Comprehensive logging: Who, what, when, where

Generated Logging: 

// Automatic audit logging
auditLog.record({
  timestamp: new Date(),
  actor: req.user.id,
  action: 'READ',
  resource: 'Patient',
  resourceId: patientId,
  ipAddress: req.ip,
  userAgent: req.headers['user-agent']
});

Example Audit Log: 

{
  "timestamp": "2026-01-15T10:30:00Z",
  "actor": "doctor-123",
  "action": "READ",
  "resource": "Patient",
  "resourceId": "patient-456",
  "ipAddress": "192.168.1.100",
  "userAgent": "Mozilla/5.0 ...",
  "authorized": true
}

3. Encryption (§164.312(a)(2)(iv), §164.312(e)(2)(ii))

Requirement: Encrypt PHI at rest and in transit.

USL Support: - Secret types: Secret<Encrypted> for PHI - TLS enforcement: HTTPS required in production - Key management: Environment-based key storage

Example: 

entity Patient {
  id: String
  name: Secret<Encrypted>                // PHI encrypted
  ssn: Secret<Encrypted>                 // PHI encrypted
  medicalRecordNumber: Secret<Encrypted> // PHI encrypted
  diagnoses: List<Diagnosis>             // Stored encrypted
}

Generated Encryption: 

// AES-256-GCM encryption
const ALGORITHM = 'aes-256-gcm';
const KEY = Buffer.from(process.env.PHI_ENCRYPTION_KEY!, 'base64');

function encryptPHI(plaintext: string): string {
  // ... encryption code (see Secret Types section)
}

TLS Configuration: 

# Generated nginx.conf
server {
  listen 443 ssl http2;
  ssl_certificate /etc/ssl/certs/server.crt;
  ssl_certificate_key /etc/ssl/private/server.key;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5;

  # Force HTTPS
  add_header Strict-Transport-Security "max-age=31536000" always;
}

4. Data Integrity (§164.312©(1))

Requirement: Protect PHI from improper alteration or destruction.

USL Support: - Invariants: Data constraints enforced - Transaction integrity: Database transactions - Immutable audit logs: Append-only logging

Example: 

entity Prescription {
  id: String
  patientId: String
  medication: String
  dosage: String
  prescribedBy: String
  prescribedAt: DateTime

  invariant ValidDosage {
    dosage.matches(/^\d+(\.\d+)?\s*(mg|g|ml)$/)
  }

  invariant PrescribedByDoctor {
    User.findById(prescribedBy).role == "doctor"
  }
}

behavior CreatePrescription(
  actor: User, 
  patient: Patient, 
  medication: String,
  dosage: String
) -> Prescription {
  authorize CanPrescribe(actor, patient)

  // Invariants checked automatically
  return Prescription {
    id: generateId(),
    patientId: patient.id,
    medication: medication,
    dosage: dosage,
    prescribedBy: actor.id,
    prescribedAt: now()
  }
}

5. Authentication (§164.312(d))

Requirement: Verify that persons seeking access to PHI are who they claim to be.

USL Support: - JWT authentication: Generated middleware - Multi-factor authentication: Configurable - Session management: Secure token handling

Generated Authentication: 

// JWT-based authentication
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET!);

    // Verify user still exists and is active
    const user = await User.findById(payload.userId);
    if (!user || !user.active) {
      return res.status(401).json({ error: 'Invalid user' });
    }

    req.user = user;
    next();
  } catch (error) {
    return res.status(401).json({ error: 'Invalid token' });
  }
}

MFA Support (configurable): 

policy CanAccessPHI(user: User) {
  user.active == true &&
  user.mfaEnabled == true &&
  user.lastMfaCheck.plusMinutes(30) > now()
}

6. Transmission Security (§164.312(e)(1))

Requirement: Implement technical security measures to guard against unauthorized access to PHI transmitted over networks.

USL Support: - TLS enforcement: All API traffic encrypted - Certificate validation: No self-signed certs in production - Secure headers: HSTS, CSP, etc.

Generated Configuration: 

# Kubernetes ingress with TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: tls-secret

HIPAA Compliance Checklist

Requirement USL Support Manual Steps Required
Access controls ✅ Policy enforcement Document access policies
Audit controls ✅ Generated logging Regular audit log review
Encryption (at rest) ✅ Secret types Key rotation procedures
Encryption (in transit) ✅ TLS enforcement Certificate management
Data integrity ✅ Invariants Regular integrity checks
Authentication ✅ JWT/MFA User provisioning process
Transmission security ✅ TLS/headers Network security
Business Associate Agreements ❌ Not provided Legal counsel
Risk assessment ❌ Not provided Annual risk assessment
Workforce training ❌ Not provided HIPAA training program

PCI-DSS Compliance

Overview

PCI-DSS regulates cardholder data (credit card numbers, etc.). Key requirements: - Protect cardholder data: Encryption and tokenization - Access control: Restrict access to cardholder data - Encryption: Data encrypted in transit and at rest - Audit trails: Track all access to cardholder data - Regular testing: Security testing and monitoring

USL Features for PCI-DSS

1. Protect Cardholder Data (Req. 3)

Requirement: Protect stored cardholder data through encryption or tokenization.

USL Support: - Tokenized secrets: Secret<Tokenized> for card numbers - No plain storage: Card numbers never stored in plain text - External tokenization: Integration with payment processors

Example: 

entity PaymentMethod {
  id: String
  userId: String
  cardToken: Secret<Tokenized>  // Tokenized, not plain card number
  last4Digits: String            // Only last 4 digits stored
  expiryMonth: Int               // Non-sensitive
  expiryYear: Int                // Non-sensitive
  cardType: String               // Visa, Mastercard, etc.
}

behavior AddPaymentMethod(
  user: User, 
  cardNumber: String,  // Plain card number (input only)
  expiry: String,
  cvv: String
) -> PaymentMethod {
  authorize CanAddPaymentMethod(user)

  // Tokenize immediately
  let token = StripeService.tokenize(cardNumber, expiry, cvv)

  return PaymentMethod {
    id: generateId(),
    userId: user.id,
    cardToken: token,  // Tokenized
    last4Digits: cardNumber.substring(cardNumber.length - 4),
    expiryMonth: expiry.split("/")[0].toInt(),
    expiryYear: expiry.split("/")[1].toInt(),
    cardType: detectCardType(cardNumber)
  }
}

Generated Code: 

import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

async function tokenizeCard(
  cardNumber: string,
  expMonth: number,
  expYear: number,
  cvv: string
): Promise<string> {
  const token = await stripe.tokens.create({
    card: {
      number: cardNumber,
      exp_month: expMonth,
      exp_year: expYear,
      cvc: cvv
    }
  });

  // Return token, not card number
  return token.id;  // "tok_..."
}

Key Point: Card number is never stored, only the token.

2. Restrict Access to Cardholder Data (Req. 7)

Requirement: Restrict access to cardholder data to those with legitimate business need.

USL Support: - Policy enforcement: Only authorized users access payment methods - Role-based access: Payment processing requires specific role - Audit logging: All access logged

Example: 

policy CanAccessPaymentMethod(actor: User, paymentMethod: PaymentMethod) {
  actor.id == paymentMethod.userId ||  // User owns the payment method
  actor.role == "payment_admin"        // Or has payment admin role
}

behavior GetPaymentMethod(actor: User, id: String) -> PaymentMethod {
  let pm = PaymentMethod.findById(id)
  authorize CanAccessPaymentMethod(actor, pm)
  expose Read[PaymentMethod]
}

3. Encrypt Transmission (Req. 4)

Requirement: Encrypt transmission of cardholder data across open, public networks.

USL Support: - TLS enforcement: All API traffic encrypted - Strong ciphers: TLS 1.2+ with strong cipher suites - Certificate validation: No weak certificates

Generated Configuration: (Same as HIPAA TLS configuration)

4. Track and Monitor Access (Req. 10)

Requirement: Track and monitor all access to network resources and cardholder data.

USL Support: - Comprehensive audit logging: All cardholder data access logged - Immutable logs: Write-only audit trail - Anomaly detection: Unusual access patterns flagged

Generated Logging: 

auditLog.record({
  timestamp: new Date(),
  actor: req.user.id,
  action: 'READ',
  resource: 'PaymentMethod',
  resourceId: paymentMethodId,
  ipAddress: req.ip,
  userAgent: req.headers['user-agent'],
  pciRelevant: true  // Flag PCI-relevant actions
});

5. Regularly Test Security (Req. 11)

Requirement: Regularly test security systems and processes.

USL Support: - Automated testing: 232 integration tests - Fuzzing: Continuous fuzzing of parser and codegen - Dependency scanning: cargo audit in CI/CD - Penetration testing: Manual (user responsibility)

CI/CD Integration: 

# Generated .github/workflows/security.yml
name: Security Tests
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run cargo audit
        run: cargo audit
      - name: Run tests
        run: cargo test --all
      - name: Run fuzzing
        run: |
          cd fuzz
          cargo +nightly fuzz run parser_fuzzer -- -max_total_time=300

PCI-DSS Compliance Checklist

Requirement USL Support Manual Steps Required
Protect cardholder data ✅ Tokenization Payment processor agreement
Restrict access ✅ Policy enforcement Document access policies
Encrypt transmission ✅ TLS enforcement Certificate management
Track and monitor ✅ Audit logging Regular log review
Regular testing ✅ Automated tests Quarterly penetration tests
Maintain security policy ❌ Not provided Security policy document
Network segmentation ⚠️ Kubernetes policies Firewall configuration
Vulnerability management ✅ Dependency scanning Quarterly vulnerability scans
Secure systems ✅ Container security Hardened OS configuration

Summary

Compliance Features Matrix

Feature GDPR HIPAA PCI-DSS
Secret types ✅ ✅ ✅
Policy enforcement ✅ ✅ ✅
Audit logging ✅ ✅ ✅
Data encryption ✅ ✅ ✅
TLS enforcement ✅ ✅ ✅
Generated APIs ✅ ✅ ✅
Access controls ✅ ✅ ✅
Data minimization ✅ ⚠️ ⚠️
Consent management ✅ ❌ ❌
Tokenization ⚠️ ⚠️ ✅

What USL Provides

✅ Technical Controls: - Encryption at rest and in transit - Access control enforcement - Audit logging - Secure code generation - Vulnerability prevention

What USL Does NOT Provide

❌ Organizational Controls: - Legal agreements (DPAs, BAAs, etc.) - Privacy policies - Security policies - Training programs - Incident response plans - Risk assessments - Compliance certifications

Recommendations

  1. Consult Legal Counsel: Compliance requires legal review
  2. Conduct Risk Assessment: Identify and mitigate risks
  3. Implement Processes: Technical controls alone are insufficient
  4. Regular Audits: Third-party audits for certifications
  5. Training: Ensure team understands compliance requirements
  6. Documentation: Maintain compliance documentation
  7. Monitoring: Continuous monitoring for compliance drift

For questions, contact: security@usl-lang.org

Disclaimer: This guide is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for compliance certification.