Vendor Management

Overview

MenoTime relies on third-party vendors and cloud services to deliver its platform. All vendors that handle PHI or have access to sensitive systems must be rigorously assessed and managed according to HIPAA requirements and MenoTime's security standards.

Golden Rule: A vendor's security is part of MenoTime's security. Never grant access to sensitive systems without proper due diligence.

Vendor Categories

1. Cloud Services (AWS)

Vendor: Amazon Web Services Relationship: Infrastructure provider (IaaS) PHI Access: YES (stores encrypted PHI) BAA Status: SIGNED ✓ Risk Level: Critical (foundational infrastructure)

Key Protections: - Business Associate Agreement in place - Data encrypted at rest and in transit - AWS shared responsibility model documented - Annual third-party audit (SOC 2 Type II) - AWS compliance certifications (ISO 27001, HIPAA, FedRAMP)

AWS-Specific Requirements: - All data encrypted with customer-managed KMS keys - VPC isolation for MenoTime infrastructure - No third-party access to MenoTime data - AWS maintains comprehensive audit logs - Data breach notification requirement in BAA

2. SaaS Tools

Examples: Slack, GitHub, Datadog, Okta

Tool	Purpose	PHI Access	BAA	Approved	Risk Level
Slack	Communication	NO	Not needed	✓ Yes	Low
GitHub Enterprise	Source control	NO (code only)	Not needed	✓ Yes	Medium
Datadog	Monitoring/logs	Partial*	Signed	✓ Yes	Medium
Okta	Identity mgmt	NO (auth metadata only)	Not needed	✓ Yes	Medium
AWS	Infrastructure	YES	Signed	✓ Yes	Critical

*Datadog sees log data, but NOT in plaintext (encrypted before transmission)

3. Email Service

Vendor: AWS SES (Simple Email Service) Relationship: Email delivery (transactional, no sensitive content) PHI Access: NO (no PHI in email) BAA Status: Covered under AWS BAA ✓ Risk Level: Low

Rules: - Never send PHI via email (this is a HIPAA rule, not SES-specific) - Secure file links or download tokens instead of attachments - Use encryption for any sensitive non-PHI data - No credentials, API keys, or secrets in email

4. Development and Testing Tools

Examples: Auth0, Stripe (for testing), SendGrid

Assessment Requirements: - Does it handle PHI? (YES = BAA required) - Data residency (where is data stored?) - Encryption standards - Security certifications (SOC 2, ISO 27001, etc.) - Data breach notification terms - Subprocessor disclosure

Vendor Assessment Process

Step 1: Initial Risk Assessment

Before engaging any vendor, complete a risk assessment:

Questionnaire:

VENDOR SECURITY ASSESSMENT
Vendor Name: _____________________
Category: ☐ Cloud ☐ SaaS ☐ Professional Services ☐ Hardware ☐ Other

1. DOES THIS VENDOR HANDLE PHI?
   ☐ No (PHI not accessed) → LOW risk, no BAA required
   ☐ Yes (PHI access required) → MEDIUM/HIGH risk, BAA required

2. DATA PROTECTION
   ☐ Encryption at rest (AES-256 or equivalent)
   ☐ Encryption in transit (TLS 1.2+)
   ☐ Customer-managed encryption keys
   ☐ Data residency in US only
   ☐ No third-party access to customer data

3. SECURITY CERTIFICATIONS
   ☐ SOC 2 Type II (most recent audit)
   ☐ ISO 27001
   ☐ HIPAA compliance certification
   ☐ FedRAMP (for federal systems)
   ☐ Other: _________________

4. OPERATIONAL SECURITY
   ☐ Incident response procedures documented
   ☐ Breach notification within 60 days
   ☐ Security event logging
   ☐ Access controls and MFA
   ☐ Regular security updates

5. DATA HANDLING
   ☐ Minimal data collection (principle of least data)
   ☐ No data sharing with third parties
   ☐ Data deletion upon contract termination
   ☐ Data portability (can export data)
   ☐ No automated decision-making on PHI

6. CONTRACTUAL TERMS
   ☐ Data Processing Agreement available
   ☐ Subprocessor notification required
   ☐ Audit rights granted to customer
   ☐ Data protection terms aligned with HIPAA
   ☐ Liability and indemnification clauses

ASSESSMENT RESULT:
☐ APPROVED (all major items checked)
☐ CONDITIONAL (missing items must be resolved before use)
☐ DENIED (too risky; use alternative vendor)

Approved by: _________________ Date: __________

Step 2: Legal Review

For vendors with PHI access, Legal team must:

Review vendor's Data Processing Agreement (DPA)
Does it meet HIPAA requirements?
Is PHI handling adequately protected?
Are subprocessors identified?
Are audit rights granted?
Negotiate Business Associate Agreement (BAA)
Standard HIPAA BAA language required
MenoTime customizations (if any)
Data breach notification procedures (60-day requirement)
Data destruction upon termination
Permissible uses and disclosures
Document Subprocessors
Does vendor use third parties? (e.g., cloud hosting)
Does subprocessor handle PHI?
Is subprocessor BAA'd?
Notification process if subprocessor changes

Step 3: Technical Verification

Security team verifies technical claims:

For Cloud/Infrastructure Vendors: - Verify encryption algorithms (AES-256, TLS 1.2+) - Review data center physical security - Confirm ISO 27001 or SOC 2 audit - Validate disaster recovery and backup procedures - Review incident response capabilities

For SaaS Vendors: - Review security documentation and audit reports - Confirm data residency and retention policies - Verify API security (authentication, rate limiting) - Test access controls and permission models - Review subprocessor list

Example: Okta Security Verification

# Verify Okta SOC 2 compliance
curl -s https://www.okta.com/trust/ | grep -i "soc 2"

# Review Okta security posture
curl -s https://api.okta.com/.well-known/openid-configuration | jq .

# Verify TLS version support
openssl s_client -tls1_2 -connect okta.com:443 < /dev/null

Step 4: Contract Execution

Before any vendor is used:

✓ Security assessment complete and approved
✓ Legal review complete
✓ BAA signed (if PHI access)
✓ DPA signed (if data processing)
✓ Vendor added to approved vendor list
✓ Subprocessor list documented
✓ Access control provisioning complete

Approved Vendor List

Critical Infrastructure (PHI Access)

Vendor	Service	BAA	Risk Level	Review Date
AWS	Cloud hosting	✓ Signed	Critical	2024-01-15

SaaS and Services (No PHI)

Vendor	Service	DPA	Certifications	Risk Level	Review Date
GitHub Enterprise	Source control	✓ Signed	SOC 2 Type II	Medium	2024-01-15
Okta	Identity/MFA	✓ Signed	SOC 2 Type II, ISO 27001	Medium	2024-01-15
Datadog	Monitoring	✓ Signed	SOC 2 Type II	Medium	2024-01-15
Slack	Communication	✓ Signed	SOC 2 Type II	Low	2024-01-15

Unapproved Vendors

Vendor	Service	Reason	Alternative
Dropbox (personal)	File sync	No SOC 2, unclear encryption	AWS S3
Personal email	Communication	Unencrypted, retention unknown	Company email
Zoom (free)	Conferencing	Limited security features	Zoom paid plan

Subprocessor Management

Subprocessor Definition

A subprocessor is a vendor that handles data on behalf of the primary vendor. For example: - AWS uses third-party data centers (regions/AZs) - Okta may use AWS or other cloud providers - GitHub uses Microsoft Azure

Subprocessor Notification

MenoTime must:

Maintain subprocessor list (documented)
Notify customers if subprocessor changes
Require subprocessor BAA (contract flow-down)
Audit subprocessor compliance (annually)

Subprocessor Disclosure Process:

Vendor provides list of subprocessors
Legal reviews subprocessor terms
Security team assesses risk
If risky: negotiate removal or replacement
Document final subprocessor list

Example AWS Subprocessor Identification:

# AWS publishes list of subcontractors
curl -s https://d0.awsstatic.com/legal/operationalrisks/index.html
# Lists AWS regions, data centers, and any AWS-owned subprocessors

Vendor Data Access and Controls

Access Levels

Level 1: No Data Access - Read documentation only - No system access - Examples: Consultant, vendor rep

Level 2: Limited Read-Only - Can view logs/metrics (non-PHI) - Cannot access application data - Examples: Monitoring tools, log analysis

Level 3: Application Data (No PHI) - Can access source code, test data - Explicit prohibition on PHI access - Examples: GitHub (code repository)

Level 4: Production Access (Non-PHI) - Full production access (metrics, logs, infrastructure) - Encrypted logs, no PHI visibility - Examples: AWS, Datadog (monitoring)

Level 5: PHI Access (Rare) - Can access or process PHI - Requires HIPAA BAA and strict controls - Examples: AWS infrastructure (encrypted PHI at rest)

Controlling Vendor Access

AWS IAM for Vendor Access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VendorReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "logs:GetLogEvents"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:username": "vendor-monitoring-tool"
        }
      }
    },
    {
      "Sid": "ProhibitPHIAccess",
      "Effect": "Deny",
      "Action": [
        "rds-db:connect",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:rds-db:*:ACCOUNT_ID:dbuser:*/menotime_app",
        "arn:aws:s3:::menotime-prod-data/*"
      ]
    }
  ]
}

Time-Limited Access:

# terraform/vendor-access.tf
resource "aws_iam_user" "vendor_monitoring" {
  name = "vendor-datadog"
}

# Access expires after 1 year
resource "aws_iam_policy" "vendor_monitoring_policy" {
  name = "vendor-datadog-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "cloudwatch:GetMetricStatistics",
          "logs:GetLogEvents"
        ]
        Resource = "*"
        Condition = {
          DateGreaterThan = {
            "aws:CurrentTime" = "2024-01-01T00:00:00Z"
          }
          DateLessThan = {
            "aws:CurrentTime" = "2025-01-01T00:00:00Z"
          }
        }
      }
    ]
  })
}

Annual Vendor Review

Review Schedule

Every vendor is reviewed annually to ensure:

Compliance status (certifications still valid)
Contractual obligations (BAA/DPA still in force)
Security incidents (did vendor have a breach?)
Access usage (is vendor still needing access?)
Cost and value (is vendor still necessary?)
SLA performance (is vendor meeting performance targets?)

Annual Review Checklist

VENDOR ANNUAL REVIEW
Vendor: _____________________ Review Date: __________

COMPLIANCE:
☐ SOC 2/ISO 27001 certification still valid? (expiration date: ___)
☐ No known security breaches in past year?
☐ Compliant with HIPAA/GDPR requirements?
☐ Signed BAA/DPA current and in force?

CONTRACTUAL:
☐ Contract not expired? (expiration date: ___)
☐ Pricing terms competitive?
☐ SLA terms being met?
☐ Data breach notification procedure tested?

SECURITY:
☐ No unauthorized access incidents?
☐ No data exposure or compromise?
☐ Subprocessor list unchanged?
☐ Security controls functioning?

OPERATIONAL:
☐ Vendor still needed for business function?
☐ Utilization level adequate (cost-benefit)?
☐ No viable replacement available?
☐ Performance/uptime acceptable?

DECISION:
☐ CONTINUE (vendor meets all requirements)
☐ CONDITIONAL (must address items below before renewal)
☐ TERMINATE (replace with alternative vendor)

Issues to address:
- _______________________________________________
- _______________________________________________

Reviewed by: _________________ Date: __________
Approved by: _________________ Date: __________

Vendor Offboarding

Termination Procedures

When a vendor relationship ends:

Immediate (Day 1): 1. Revoke all access credentials 2. Disable API keys and tokens 3. Remove from AWS IAM 4. Confirm access is blocked (test login)

Short-Term (Days 1-7): 1. Retrieve any data vendor has (if applicable) 2. Verify data deletion from vendor systems 3. Confirm no outstanding backup access 4. Remove from documentation and runbooks

Documentation: 1. Document data deletion confirmation 2. Record termination date and reason 3. Archive vendor assessment documents 4. Update approved vendor list

Example: Slack Offboarding

# Revoke bot token
curl -X POST https://slack.com/api/auth.revoke \
  -H "Authorization: Bearer xoxb-TOKEN" \
  -d "token=xoxb-TOKEN"

# Remove workspace application
# (Manual step in Slack workspace settings)

# Export workspace data (if needed)
aws s3 sync slack-export/ s3://menotime-exports/slack/

Vendor Security Incident Response

If Vendor Has a Breach

If a vendor experiences a security breach:

Immediate (< 1 hour)
Notify MenoTime Security Officer
Determine scope (what MenoTime data was exposed?)
Assess if MenoTime PHI was compromised
Day 1
Vendor must provide breach notification
Review vendor's incident response report
Assess impact on MenoTime systems
Determine if customer notification required
Days 1-60
Investigate vendor's incident (audit logs, access patterns)
Determine if re-attestation or remediation needed
Document findings
Notify customers if MenoTime PHI was exposed
Decision
Continue vendor with enhanced controls?
Terminate vendor immediately?
Require security improvements before continuing?

Vendor Security Incident Checklist

VENDOR BREACH ASSESSMENT
Vendor: _____________________ Incident Date: __________
Breach Notification Received: ________________

INITIAL ASSESSMENT:
☐ What data was exposed? (describe)
☐ Does MenoTime data fall in scope?
☐ Was PHI compromised? (YES/NO)
☐ How many MenoTime records affected? ______

IMPACT DETERMINATION:
☐ Confidentiality impact? (data disclosure)
☐ Integrity impact? (data modification)
☐ Availability impact? (system downage)
☐ Regulatory impact? (HIPAA breach? YES/NO)

RESPONSE ACTIONS:
☐ Notify affected customers (if PHI exposed)
☐ Rotate MenoTime credentials in vendor
☐ Review vendor's incident response
☐ Increase monitoring of vendor access
☐ Assess continued vendor relationship

DECISION:
☐ CONTINUE (incident contained, vendor acceptable)
☐ CONDITIONAL (require vendor remediation plan)
☐ TERMINATE (breach unacceptable, replace vendor)

Decision made by: _________________ Date: __________

Vendor Compliance Reporting

Quarterly Vendor Summary

Quarterly report to executive leadership:

VENDOR COMPLIANCE REPORT - Q1 2024

VENDOR STATUS:
- Total active vendors: 8
- Vendors with PHI access: 1 (AWS)
- Vendors with signed BAA: 1
- Vendors with SOC 2 certification: 7/8

SECURITY INCIDENTS:
- Vendor-related incidents: 0
- Vendor access violations: 0
- Unauthorized access attempts: 0

ACTIONS TAKEN:
- Annual reviews completed: 3
- New vendor onboarding: 1 (GitHub Enterprise)
- Vendor offboarding: 1 (old monitoring tool)
- Security assessments: 2

UPCOMING:
- AWS BAA renewal: Q2 2024
- Datadog SOC 2 review: Q2 2024
- Okta annual audit: Q3 2024

RISKS:
- No high-risk vendors identified
- All BAAs current and valid
- No compliance gaps identified

Compliance Checklist

✓ All vendors with PHI access have signed BAA
✓ All vendors with data processing have signed DPA
✓ Annual security assessments completed for all vendors
✓ Subprocessor list maintained and reviewed annually
✓ Vendor access controls implemented (least privilege)
✓ Vendor access monitored and logged
✓ Time-limited access for vendors (automatic revocation)
✓ Data deletion procedures documented and tested
✓ Vendor incident response procedures established
✓ Quarterly vendor compliance reports generated
✓ Approved vendor list maintained and updated
✓ Unapproved vendors banned from access

Questions? Contact the Security Officer at security@timelessbiotech.com or the Privacy Officer at privacy@timelessbiotech.com.