Skip to content

Security Controls Documentation

Document ID: PLCY-SEC-001
Effective Date: December 22, 2025
Last Review: December 22, 2025
Owner: Hop And Haul Team


CONFIDENTIAL

This document is CONFIDENTIAL and for internal use only. Do not distribute outside the organization.

1. Purpose

This document defines the security controls implemented in Hop And Haul to satisfy SOC II Common Criteria (CC) requirements for Security, Availability, and Processing Integrity.


2. Control Framework Mapping

SOC II CriteriaControl AreaSection
CC6.1Logical Access Controls3.1
CC6.2System Access Authentication3.2
CC6.3Access Authorization3.3
CC6.6Encryption4
CC6.7Transmission Security5
CC7.1Vulnerability Management6
CC7.2System Monitoring7
CC7.3Change Management8

3. Logical Access Controls (CC6.1, CC6.2, CC6.3)

3.1 Server-Side Enforcement

Control: All matching logic executes server-side only

RequirementImplementation
No client-side route calculationsMatching API returns only approved results
No full route exposure pre-matchClient receives fuzzed location only
No driver PII before acceptanceNames/contact hidden until match confirmed

Rationale: Prevents data leakage through client-side code inspection or manipulation.

3.2 Authentication Controls

ControlSpecification
Identity providerSSO integration required
Multi-factor authenticationRequired for Ops/Safety, Admin roles
Mobile authenticationSSO + device PIN/biometric
Session managementServer-side session tracking
Password policyManaged by corporate SSO

3.3 Token Management

Token TypeLifetimeScopeRevocation
Session token8 hours maxUser sessionLogout or timeout
Ride tracking tokenUntil drop-off + 15 minSingle rideAuto-expire
API bearer token24 hoursService integrationRotation policy
Refresh token7 daysToken renewalRevocation list

Auto-Expiration: Tracking tokens automatically invalidate after ride completion to prevent stale access.

3.4 Time-Limited Access

Access TypeDurationExtension
Ride offer visibility15 minutesNone
Post-match contact accessRide duration + 15 minNone
Rating submission window24 hours post-completionNone
Admin session4 hoursMFA re-verification

4. Encryption Controls (CC6.6)

4.1 Data at Rest

Data StoreEncryption MethodKey Management
Primary databaseAES-256-GCMAWS KMS / equivalent
Backup storageAES-256Separate key hierarchy
Log storageAES-256Log-specific keys
File attachmentsAES-256Per-tenant keys

4.2 Data in Transit

Connection TypeProtocolMinimum Version
Client to APITLS1.3
API to databaseTLS1.2 (1.3 preferred)
Service to servicemTLS1.2
External integrationsTLS1.2

4.3 Key Rotation

Key TypeRotation FrequencyProcess
Master encryption keysAnnuallyAutomated with overlap
Service API keysQuarterlyZero-downtime rotation
Session signing keysMonthlyAutomated
TLS certificatesAnnuallyAutomated renewal

5. Transmission Security (CC6.7)

5.1 Data Minimization in Transit

Data ElementPre-Match TransmissionPost-Match Transmission
Driver locationFuzzed (1-2 mi radius)Precise pickup point
Driver identityNot transmittedFirst + last initial only
Phone numberNot transmittedMasked format
Full routeNot transmittedOwn route only
Other driver routesNever transmittedNever transmitted

5.2 API Security

ControlImplementation
Rate limitingPer-user and per-endpoint
Request validationSchema validation on all inputs
Response filteringRole-based field exclusion
CORS policyStrict origin allowlist
API versioningDeprecation policy enforced

5.3 Location Data Protection

Fuzzification Algorithm:

  • Pre-match: Random offset within 1-2 mile radius
  • Direction displayed as city/region only
  • Precise coordinates only after mutual acceptance

Fuzzification Algorithm Details:

AspectSpecification
Offset typeRandom within radius
Radius1-2 miles (configurable per company)
RefreshNew random offset per offer (not per session)
DeterminismNon-deterministic to prevent triangulation
Minimum samplesCannot derive true location from <10 offers
Direction biasNone (uniform distribution within radius)

Anti-Triangulation Measures:

  • Each offer generates a new random offset
  • Offsets are not correlated across offers
  • No persistent offset tied to driver identity
  • Statistical analysis of multiple declines does not reveal true position

6. Vulnerability Management (CC7.1)

6.1 Vulnerability Scanning

Scan TypeFrequencyScope
Automated SASTEvery commitApplication code
Dependency scanningDailyThird-party libraries
Container scanningEvery buildDocker images
Infrastructure scanningWeeklyCloud resources
Penetration testingAnnuallyFull application

6.2 Remediation SLAs

SeverityResponse TimeRemediation Time
Critical4 hours24 hours
High24 hours7 days
Medium72 hours30 days
Low7 days90 days

6.3 Patch Management

ComponentPatch WindowTesting Required
Critical securityEmergencySmoke tests
OS/infrastructureMonthlyFull regression
Application dependenciesBi-weeklyIntegration tests

7. System Monitoring (CC7.2)

7.1 Security Event Logging

See PLCY-RET-001 Records Retention Policy for authoritative retention schedule.

Event CategoryLogged ElementsRetention
AuthenticationSuccess/failure, IP, device24 months
AuthorizationAccess granted/denied, resource24 months
Data accessUser, data type, timestamp24 months
Configuration changesUser, change detail, timestamp24 months
Security alertsAlert type, severity, response24 months

Retention periods aligned with PLCY-RET-001 for consistency across all security logs.

7.2 Alerting Thresholds

ConditionThresholdResponse
Failed login attempts5 in 15 minutesAccount lockout, alert
Unusual access patternML anomaly detectionSecurity review
Privilege escalation attemptAny occurrenceImmediate alert
Data export volume>100 recordsManager notification

7.3 Log Protection

ControlImplementation
Log integrityAppend-only storage
Access restrictionSecurity team only
Tampering detectionCryptographic checksums
BackupSeparate secure location

8. Change Management (CC7.3)

8.1 Change Categories

CategoryApproval RequiredTesting Required
EmergencyPost-implementation reviewMinimal
StandardCAB approvalFull
Pre-approvedTemplate-basedAutomated

8.2 Deployment Controls

ControlRequirement
Code reviewMinimum 1 approver
Automated testingAll tests pass
Security scanNo critical findings
Rollback planDocumented before deploy
Change windowDefined maintenance periods

9. Physical Security

9.1 Cloud Infrastructure

ControlImplementation
Data center securitySOC II certified provider
Geographic restrictionsData residency enforced
Network isolationVPC/private networking
DDoS protectionCloud-native protection

10. Document Control

VersionDateAuthorChanges
1.0[DATE][NAME]Initial release
1.1December 30, 2025Hop And Haul TeamAdded NIST 800-53 mapping

11. NIST 800-53 Control Mapping

This section maps Hop And Haul security controls to NIST 800-53 Rev 5 for FedRAMP Moderate compliance.

11.1 Access Control (AC) Family

ControlTitleSection ReferenceStatus
AC-3Access Enforcement3.1, 3.3Implemented
AC-4Information Flow Enforcement5.1Implemented
AC-6Least Privilege3.2, 3.3Implemented
AC-7Unsuccessful Logon Attempts7.2Implemented
AC-11Device Lock3.4Implemented
AC-17Remote Access9.1Implemented

11.2 System & Communications Protection (SC) Family

ControlTitleSection ReferenceStatus
SC-8Transmission Confidentiality4.2, 5Implemented
SC-12Cryptographic Key Management4.3Implemented
SC-13Cryptographic Protection4.1, 4.2Implemented
SC-23Session Authenticity3.3Implemented
SC-28Protection of Information at Rest4.1Implemented

11.3 Configuration Management (CM) Family

ControlTitleSection ReferenceStatus
CM-3Configuration Change Control8Implemented
CM-7Least Functionality3.1Implemented

11.4 System & Information Integrity (SI) Family

ControlTitleSection ReferenceStatus
SI-2Flaw Remediation6Implemented
SI-4System Monitoring7Implemented
SI-10Information Input Validation5.2Implemented

11.5 FedRAMP-Specific Enhancements (Planned)

EnhancementTarget ControlTimeline
FIPS 140-2 validated modulesSC-13Phase 3
PIV/CAC authenticationIA-2(12)Phase 3
File integrity monitoringSI-7Phase 3

For complete NIST 800-53 control mapping, see Control Mapping Matrix.

CONFIDENTIAL - Internal Use Only - Hop And Haul Policy Documentation