Advisory API Systems LLC
Security Practices Documentation
Effective Date: Upon First API Use
Version: 1.4
Last Updated: April 2026
1. INTRODUCTION
1.1 Purpose
This Security Practices Documentation describes the technical and organizational security measures implemented by Advisory API Systems LLC (“Company”) to protect the Portfolio Optimization API and the data processed through it.
1.2 Commitment to Security
Advisory API Systems is committed to maintaining the confidentiality, integrity, and availability of customer data. We implement security measures commensurate with the sensitivity of data processed and industry best practices.
1.3 Scope
This documentation covers security practices applicable to:
- API infrastructure and services
- Data transmission and storage
- Access controls and authentication
- Incident response
- Personnel security
2. ORGANIZATIONAL SECURITY
2.1 Security Governance
Security Responsibility:
The Chief Compliance Officer serves as the security officer responsible for information security policy, implementation, and oversight.
Security Reviews:
Security practices are reviewed at least annually and updated as needed based on:
- Threat landscape changes
- Technology updates
- Regulatory requirements
- Incident lessons learned
2.2 Personnel Security
Background Checks:
Personnel with access to production systems and customer data undergo background verification.
Confidentiality Agreements:
All personnel sign confidentiality agreements as a condition of engagement.
Security Training:
Personnel receive security awareness training covering:
- Data handling procedures
- Phishing and social engineering awareness
- Incident reporting
- Password and access management
Access Termination:
Access privileges are revoked immediately upon personnel termination or role change.
2.3 Vendor Management
Third-party vendors with access to customer data or systems are:
- Evaluated for security practices prior to engagement
- Subject to periodic security reviews
- Limited to necessary access only
3. INFRASTRUCTURE SECURITY
3.1 Hosting Environment
Cloud Infrastructure:
The API is hosted on enterprise-grade cloud infrastructure located in Germany (European Union), benefiting from the strict data protection requirements of the EU General Data Protection Regulation (GDPR). Infrastructure features include:
- Geographic redundancy within the EU
- 24/7 infrastructure monitoring
- DDoS protection
Network Security:
- Firewall protection with default-deny policies
- Network segmentation between components
- Intrusion detection/prevention systems
- Regular vulnerability scanning
3.2 System Hardening
Server Configuration:
- Minimal software installation (reduced attack surface)
- Unnecessary services disabled
- Security patches applied promptly
- Configuration management with version control
Operating Systems:
- Current, supported operating system versions
- Security updates installed regularly
- Anti-malware protection where applicable
3.3 Availability and Resilience
Redundancy:
- Multiple availability zones
- Load balancing across instances
- Database replication
- Failover capabilities
Backup and Recovery:
- Configuration backups maintained
- Recovery procedures documented and tested
- Recovery time objectives defined in SLA
4. APPLICATION SECURITY
4.1 Secure Development
Development Practices:
- Secure coding guidelines followed
- Code review for security vulnerabilities
- Separation of development and production environments
- Version control for all code changes
Vulnerability Management:
- Regular security assessments
- Dependency scanning for known vulnerabilities
- Remediation prioritized by severity
4.2 API Security
Authentication:
- Bearer token (“Access Token”) required for all requests, transmitted in the
X-User-Token HTTP header
- Access Tokens are unique per customer and generated from a cryptographically secure random source (256 bits of entropy)
- Access Tokens are stored on API infrastructure only as SHA-256 cryptographic hashes; plaintext tokens are delivered to the customer once, at issuance, and are not thereafter retained by the Company
- Access Tokens can be rotated on request or revoked immediately if compromise is suspected
- Failed authentication attempts monitored
Authorization:
- Role-based access controls
- Users can only access their own data
- Least privilege principle applied
Input Validation:
- All inputs validated and sanitized
- Protection against injection attacks
- Request size limits enforced
- Rate limiting implemented
4.3 Code Security
Dependencies:
- Third-party libraries regularly updated
- Known vulnerabilities monitored
- Minimal dependency footprint
Static Analysis:
- Security-focused code review
- Regular security audits
5. DATA SECURITY
5.1 Data Classification
Data processed by the API is classified as:
| Classification |
Description |
Handling Requirements |
| Confidential |
User financial data, PII |
Encryption, access controls |
| Internal |
API configurations, system data |
Access controls, change management |
| Public |
API documentation |
No restrictions |
5.2 Encryption
Data in Transit:
- TLS 1.2 or higher required for all API communications
- Strong cipher suites enforced
- Certificate validation required
Data at Rest:
- AES-256 encryption for stored data
- Encryption keys managed securely
- Key rotation procedures in place
5.3 Data Handling
Data Storage:
User data submitted via API requests is processed and retained after responses are delivered, including:
- Request metadata retained for operational logging
- Usage counts retained for billing
Data Minimization:
- Only necessary data collected
- Data retained only as long as needed
- Secure deletion when no longer required
5.4 Credential and Key Management
Customer Access Tokens:
- Transmitted only over TLS (HTTPS); HTTP is rejected at the edge
- Stored at rest only as SHA-256 hashes (preimage-resistant; a disclosure of the token store does not yield usable credentials)
- Can be rotated on customer request or revoked immediately on suspicion of compromise
- Token usage monitored for anomalies (rate, geography, failure patterns)
Third-Party Service Credentials (Payment Processor, Market Data, Address/VIN Validation, etc.):
- Stored outside the application source tree as operating-system environment variables, injected at service start by a systemd unit file readable only by the service account
- Not committed to version control; not included in source-code backups or zip archives of the repository
- Rotation performed directly on the production host; no code change or re-deployment required
Internal Encryption Keys:
- Stored in secure key management system
- Access strictly limited
- Rotation procedures documented
6. ACCESS CONTROL
6.1 Authentication
Administrative Access:
- Multi-factor authentication (MFA) required
- Strong password requirements enforced
- Session timeouts implemented
- Failed login lockout policies
User Access:
- Unique API Keys per customer
- Key regeneration available through secure process
6.2 Authorization
Principle of Least Privilege:
- Users granted minimum necessary access
- Access reviewed periodically
- Privileged access limited and monitored
Segregation of Duties:
- Critical functions require multiple approvals
- Development and production access separated
- Audit and operational functions separated
6.3 Access Logging
Audit Trails:
- API access logged with timestamps and API Key identifiers
- Administrative actions logged
- Log integrity protected
- Logs retained according to policy
7. NETWORK SECURITY
7.1 Perimeter Security
Firewalls:
- Web application firewall (WAF) protection
- Network firewalls with restrictive rules
- Default deny policies
DDoS Protection:
- Distributed denial-of-service mitigation
- Traffic analysis and filtering
- Automatic scaling under load
7.2 Secure Communications
API Endpoints:
- HTTPS only (HTTP redirected or blocked)
- Valid TLS certificates
- Certificate transparency monitoring
8. MONITORING AND LOGGING
8.1 Security Monitoring
Continuous Monitoring:
- Anomaly detection
- Alert thresholds configured
- On-call response procedures
Metrics Tracked:
- API availability and latency
- Error rates
- Authentication failures
- Unusual usage patterns
8.2 Logging
Log Collection:
- Centralized log aggregation
- Tamper-resistant log storage
- Log retention per policy
Log Contents:
- Timestamp
- Source IP address
- API Key identifier
- Request type and endpoint
- Response status code
- Response time
8.3 Alerting
Alert Triggers:
- Service availability issues
- Elevated error rates
- Authentication anomalies
- Security events
Response Process:
- Alerts routed to appropriate personnel
- Escalation procedures defined
- Incident response initiated as needed
9. INCIDENT RESPONSE
9.1 Incident Response Plan
Advisory API Systems maintains an incident response plan covering:
Preparation:
- Response team defined
- Contact information current
- Playbooks documented
- Tools and resources available
Detection and Analysis:
- Monitoring for incidents
- Classification by severity
- Impact assessment
- Evidence preservation
Containment and Eradication:
- Immediate containment measures
- Root cause analysis
- Remediation steps
- Verification of resolution
Recovery:
- Service restoration
- User communication
- Post-incident review
- Lessons learned documentation
9.2 Incident Classification
| Severity |
Description |
Response Time |
| Critical |
Data breach, complete service outage |
1 hour |
| High |
Significant security event, major service degradation |
4 hours |
| Medium |
Limited security event, minor service impact |
1 business day |
| Low |
Potential vulnerability, no immediate impact |
5 business days |
9.3 User Notification
Users will be notified of security incidents affecting their data:
- Within 72 hours of confirmation
- Via email to registered contacts
- With details as described in the Data Processing Agreement
10. BUSINESS CONTINUITY
10.1 Disaster Recovery
Recovery Objectives:
- Recovery Time Objective (RTO): 4 hours
- Recovery Point Objective (RPO): 1 hour
Recovery Capabilities:
- Geographic redundancy
- Regular recovery testing
10.2 Backup Procedures
System Backups:
- Configuration backups daily
- Backup encryption
- Offsite backup storage
- Restoration testing
11. COMPLIANCE
11.1 Regulatory Framework
Advisory API Systems operates in compliance with applicable regulations:
- California state investment adviser regulations
- SEC regulations (as applicable)
- California Consumer Privacy Act (CCPA)
- Gramm-Leach-Bliley Act (GLBA) safeguards
- EU General Data Protection Regulation (GDPR), as applicable to data processed on EU-based infrastructure
Details regarding the Company’s privacy practices, including CCPA/CPRA disclosures, GLBA privacy notices, and GDPR compliance, are set forth in the Privacy Policy, which is incorporated by reference into the User Agreement.
11.2 Security Assessments
Internal Assessments:
- Annual security policy review
- Quarterly vulnerability scanning
- Periodic penetration testing
12. CUSTOMER RESPONSIBILITIES
12.1 Shared Security Model
Security is a shared responsibility. Users are responsible for:
Access Token Protection:
- Store Access Tokens securely (encrypted secrets manager, OS keychain, or equivalent); do not store them in plaintext files, source code, email, chat transcripts, or public repositories
- Do not share Access Tokens across multiple individuals, systems, or environments not authorized under the Agreement
- Request Access Token rotation promptly upon any actual or suspected compromise, and in any event within twenty-four (24) hours of discovery
- Monitor own systems for unauthorized use of Access Tokens
Client-Side Security:
- Securing systems that interact with the API
- Protecting data before and after transmission
- Implementing appropriate access controls
- Maintaining secure development practices
Incident Reporting:
- Promptly reporting suspected security issues
- Cooperating with incident investigations
12.2 Security Best Practices
Users should:
- Use HTTPS for all API communications
- Validate TLS certificates
- Implement request timeouts
- Handle errors gracefully
- Log API interactions appropriately
- Regularly review access and usage
13. SECURITY QUESTIONNAIRE
The following addresses common security assessment questions:
13.1 Data Protection
| Question |
Response |
| Is data encrypted in transit? |
Yes, TLS 1.2+ required |
| Is data encrypted at rest? |
Yes, AES-256 |
| Where is data processed? |
Germany |
| How long is data retained? |
Term of Agreement; deleted upon written request subject to regulatory retention |
| Can customers delete their data? |
Yes, upon written (email) request at any time, subject to regulatory retention requirements |
13.2 Access Control
| Question |
Response |
| Is MFA required for administrative access? |
Yes |
| How is customer authentication handled? |
Bearer Access Token in X-User-Token header; 256-bit CSPRNG; SHA-256 hashed at rest |
| Is there role-based access control? |
Yes |
| Are access logs maintained? |
Yes |
13.3 Infrastructure
| Question |
Response |
| Is infrastructure hosted in certified data centers? |
Yes |
| Is there geographic redundancy? |
Yes |
| Are firewalls in place? |
Yes |
| Is there DDoS protection? |
Yes |
13.4 Compliance
| Question |
Response |
| Is there a security policy? |
Yes |
| Is there an incident response plan? |
Yes |
| Are security assessments conducted? |
Yes, annually |
| Is employee security training provided? |
Yes |
Advisory API Systems LLC
Email: [email protected]
Phone: (310) 839-0358
Security Incident Reporting:
Email: [email protected]
Subject: SECURITY INCIDENT - [Brief Description]
This Security Practices Documentation is incorporated by reference into the User Agreement. By using the API, you acknowledge that you have reviewed this documentation.