Trust Center

GenAIPI maintains a formal Information Security Risk Management Program (InfoSec RMP) aligned with NIST Cybersecurity Framework (CSF) principles and ISO 27001 best practices. The program is overseen by Brantley Brumley, Chief AI Officer (CAIO), who serves as the senior executive responsible for information security governance.

Risk Identification

We conduct ongoing risk identification through automated vulnerability scanning, dependency auditing, infrastructure monitoring, and regular threat assessments. Assets are inventoried and classified by sensitivity level, including customer data, application code, credentials, and infrastructure components.

Risk Assessment Methodology

Identified risks are assessed using a qualitative framework that evaluates likelihood and impact on a 5-point scale. Risks are categorized as Critical, High, Medium, or Low based on the combined score. Assessment considers data sensitivity, regulatory impact, business continuity, and reputational factors.

Risk Treatment

For each identified risk, we apply one of four treatment strategies: mitigate (implement controls), accept (document and monitor), transfer (insurance or contractual allocation), or avoid (eliminate the risk source). Critical and High risks require a documented treatment plan with defined timelines and accountable owners.

Monitoring & Review

The risk register is reviewed quarterly. Automated monitoring tools provide continuous visibility into vulnerability status, dependency health, and infrastructure security posture. Material changes to the risk landscape trigger ad hoc reviews.

Governance

The CAIO reports on security posture and risk status to company leadership monthly. All employees complete security awareness training upon hire and annually thereafter. Policy documents are reviewed and updated at least annually or upon significant infrastructure or regulatory changes.

All GenAIPI employees and contractors are required to sign the following Confidentiality and Acceptable Use Agreement prior to accessing any company systems or customer data.

GenAIPI maintains a documented Incident Response Policy that governs how security incidents involving our platform, data, or services are detected, contained, investigated, remediated, and reported.

Scope

This policy applies to all security events that affect the confidentiality, integrity, or availability of GenAIPI systems, customer data, or services — including but not limited to unauthorized access, data breaches, malware, denial-of-service attacks, credential compromise, and misuse of platform resources.

Incident Classification

• Critical (P1): Confirmed breach of customer data, active compromise of production systems, ransomware, or complete service outage.
• High (P2): Attempted breach with partial success, vulnerability actively exploited, unauthorized access to internal systems, or significant service degradation.
• Medium (P3): Vulnerability identified but not yet exploited, suspicious activity requiring investigation, or minor service disruption.
• Low (P4): Policy violation, phishing attempt blocked, informational security events for awareness.

Incident Response Team

The incident response team is led by the CAIO (Brantley Brumley) and includes designated technical personnel. For Critical and High incidents, company leadership is notified immediately and involved in decision-making.

Response Phases

1. Detection & Identification: Automated monitoring, log analysis, vulnerability scanning, and employee reporting channels.
2. Containment: Immediate steps to limit the scope and impact — isolating affected systems, revoking compromised credentials, and blocking malicious traffic.
3. Eradication: Identifying root cause, removing threat actors and malware, patching exploited vulnerabilities.
4. Recovery: Restoring systems from clean backups, validating integrity, and returning to normal operations.
5. Post-Incident Review: Documenting lessons learned, updating controls, revising policies as needed, and producing a final incident report.

Client Notification Criteria

Clients are notified when an incident meets any of the following criteria:

• Confirmed unauthorized access to or exfiltration of customer data
• A breach that is reasonably likely to affect the confidentiality, integrity, or availability of client data or services
• Any incident requiring notification under applicable data protection laws (e.g., GDPR, CCPA)
• Significant service outage or degradation lasting beyond published SLAs

Service Level Agreements (SLAs)

Communication Protocols

Client notifications are delivered via email to designated security contacts. Critical incidents additionally receive phone notification if a phone contact is on file. All communications include: incident description, affected data/services, containment actions taken, remediation timeline, and recommended client actions.

Escalation Procedures

1. Level 1: Technical team initiates containment and assessment.
2. Level 2: CAIO is notified and assumes incident command for P1/P2.
3. Level 3: Executive leadership and legal counsel engaged for confirmed data breaches.
4. Level 4: External incident response resources and regulatory notifications as required by law.

GenAIPI implements a continuous network vulnerability management program to identify, assess, and remediate security weaknesses across our infrastructure.

Responsible Personnel

Network vulnerability management is overseen by the CAIO (Brantley Brumley) and executed by the engineering team. External assessments are performed by qualified third-party security firms on a regular basis.

Processes & Tools

• Automated dependency scanning: All application dependencies are continuously monitored for known vulnerabilities using automated audit tools. Critical and high-severity dependency vulnerabilities trigger immediate remediation.
• Infrastructure monitoring: Our cloud hosting and database providers provide infrastructure-level security monitoring, DDoS protection, and network intrusion detection. SSL/TLS certificate validity is monitored continuously.
• AI-assisted security analysis: We leverage AI-powered security scanning tools for static analysis (SAST), dependency auditing, and configuration review, enabling rapid identification of vulnerabilities across the codebase.
• Periodic external assessments: External security audits and penetration testing are conducted on a regular basis by independent security professionals to validate our security posture.

Remediation Workflow

Vulnerabilities are prioritized by CVSS score and business context. Critical vulnerabilities (CVSS 9.0+) are addressed within 24 hours. High vulnerabilities (CVSS 7.0–8.9) are addressed within 7 days. Medium vulnerabilities (CVSS 4.0–6.9) are addressed within 30 days. Low vulnerabilities are addressed in the next scheduled maintenance cycle.

Data in Transit

• TLS 1.2 / TLS 1.3: All data transmitted between clients and our servers is encrypted using TLS 1.2 or TLS 1.3. We enforce HSTS (HTTP Strict Transport Security) with a 2-year max-age, includeSubDomains, and preload directives.
• Cipher suites: Only strong cipher suites are permitted. Weak ciphers (RC4, DES, 3DES, export-grade) are explicitly disabled.
• Certificate management: SSL/TLS certificates are managed and automatically renewed by our hosting infrastructure.

Data at Rest

• AES-256: Customer data stored in our database is encrypted at rest using AES-256 encryption, managed by the database provider's encryption-at-rest capabilities.
• Backup encryption: Database backups are encrypted using the same AES-256 standard.

Password Storage

• bcrypt: All user passwords are hashed using bcrypt with 10 salt rounds. Plaintext passwords are never stored. Legacy plaintext passwords are rejected at login, forcing a secure password reset flow.

Payment Data

GenAIPI does not store, process, or transmit raw credit card numbers or payment account data. All payment processing is handled by a PCI DSS Level 1 certified payment processor. Payment data never touches our servers.

The following communication protocols are used for transmitting customer data:

No customer data is transmitted via unencrypted protocols. HTTP requests are automatically redirected to HTTPS via HSTS enforcement and the upgrade-insecure-requests CSP directive in production.

GenAIPI's production infrastructure restricts network access to the minimum ports necessary for operation:

All other ports are closed by default. Infrastructure-level firewalls and network security groups enforce port restrictions. Database access is restricted to authorized application connections only — no public internet access to the database is permitted.

GenAIPI maintains a structured application vulnerability management program to ensure the ongoing security of our platform.

Responsible Personnel

Application security is managed by the engineering team under the oversight of the CAIO. All developers are responsible for writing secure code and participating in the code review process.

Tools & Processes

• Static Application Security Testing (SAST): AI-assisted static analysis tools scan source code for vulnerabilities, insecure patterns, and coding errors. Scans run regularly and on demand during development.
• Dependency auditing: Automated scanning tools identify known vulnerabilities in third-party packages. The dependency tree is monitored continuously.
• Code review: All code changes undergo peer review before merging. Security-sensitive changes (authentication, authorization, data handling, payment processing) receive enhanced review.
• Input validation: All user inputs are validated using schema-based validation on both client and server side. Server-side validation is enforced regardless of client-side checks.
• Output encoding: API responses are sanitized using custom sanitization functions that strip sensitive fields from user-facing data.

Patching Frequency

• Critical security patches: Applied within 24 hours of availability.
• High-severity patches: Applied within 7 days.
• Routine updates: Applied during regular maintenance cycles (bi-weekly).
• Framework and runtime updates: Evaluated and applied quarterly, or immediately if security-related.

Criticality Assessment

Patches are prioritized based on CVSS score, exploitability, affected component, and whether the vulnerability is actively exploited in the wild. Critical vulnerabilities in internet-facing components receive highest priority.

Deployment Process

Patches are tested in a development environment, reviewed for compatibility, and deployed to production through our standard deployment pipeline. Emergency patches for Critical vulnerabilities may bypass the standard review cycle but are reviewed retrospectively.

Customer Notification

Routine patches and updates are applied transparently and do not require customer notification. Customers are notified in advance of scheduled maintenance that may cause service interruption. Customers are notified after the fact when an emergency patch addresses a vulnerability that may have affected their data.

GenAIPI maintains a proactive approach to managing software that is approaching or has reached end-of-life status.

Monitoring

We actively monitor vendor announcements, community advisories, and dependency health indicators for all software components in our stack — including application runtimes, third-party packages, database systems, and infrastructure services.

Deprecation Timeline

• 12+ months before EOL: Transition planning begins. Replacement technologies are evaluated.
• 6 months before EOL: Active migration to supported alternatives commences.
• At EOL: All production use of EOL software is eliminated. Any exceptions require documented risk acceptance by the CAIO.

Support Termination

When a software component reaches EOL, it is replaced with a supported alternative. No production system runs EOL software without a documented exception and compensating controls.

Scope

Internal security audits cover access controls and permissions, secret management practices, dependency health and vulnerability status, code security (SAST findings), security header configuration, rate limiting and abuse prevention, data handling and retention compliance, and backup integrity.

Frequency & Methodology

Formal internal audits are conducted quarterly using a combination of manual review and AI-assisted security scanning tools. Continuous automated monitoring provides real-time visibility between formal audits.

Remediation

Audit findings are documented in a tracking system, assigned to owners with target remediation dates, and tracked to completion. Critical findings are escalated to the CAIO immediately. The remediation status of all audit findings is reviewed monthly.

GenAIPI implements multiple layers of defense to mitigate web application vulnerabilities:

Note on WAF: GenAIPI does not currently operate a standalone Web Application Firewall (WAF). Infrastructure-level DDoS protection and network filtering are provided by our hosting platform. Application-layer protections (CSP, rate limiting, input validation, output sanitization) provide defense-in-depth at the application level.

Secure Software Development Lifecycle (SSDLC)

GenAIPI follows a secure software development lifecycle that integrates security at every phase:

• Design: Security requirements are identified during feature planning. Threat modeling is performed for security-sensitive features.
• Development: Developers follow secure coding guidelines covering input validation, output encoding, authentication, authorization, cryptography, error handling, and logging.
• Review: All code changes undergo peer review. Security-sensitive changes (auth, payments, data handling) receive enhanced review with specific security checklists.
• Testing: Automated SAST scans run during the development process. Dependency vulnerability checks are integrated into the build pipeline.
• Deployment: Production deployments follow a controlled process with rollback capability.

Developer Security Training

All developers receive secure coding training covering OWASP Top 10 vulnerabilities, secure authentication and session management, input validation and output encoding, cryptographic best practices, and secure API design. Training is reinforced through code review feedback and is refreshed annually.

GenAIPI implements role-based access control (RBAC) across all platforms to ensure users access only the resources and data appropriate to their role. The principle of least privilege is applied — each role grants only the minimum access required.

Platform Roles

Access Control Enforcement

Role-based access is enforced at the server level through authentication middleware that verifies session validity and role authorization before processing any request. Administrative routes are protected by dedicated middleware. Granular permissions within roles (e.g., organization-scoped access) are enforced through additional data-level filtering. All access decisions follow deny-by-default — users must be explicitly granted access to protected resources.

GenAIPI implements structured secret management to protect credentials, API keys, and other sensitive configuration.

Storage & Access

• Environment variables: All secrets are stored as environment variables managed by the hosting platform's secret management system — never hardcoded in source code or committed to version control.
• Startup validation: A centralized configuration module validates that all required production secrets are present at application startup. The application will not start in production if critical secrets are missing.
• Client-side isolation: Sensitive keys, API secrets, and database credentials are strictly server-side. Only explicitly public configuration is exposed to the frontend build.
• Development safety: Development environments use separate, functionally inert credentials, preventing accidental use of production secrets during development.

Secret Categories

Managed secrets include database credentials, session encryption keys, payment processing credentials, email delivery credentials, and third-party API keys. Each secret is scoped to its specific function and rotated according to our key management policy (see Section 18).

Authentication Method

GenAIPI uses session-based authentication with secure, server-side session storage in PostgreSQL. Sessions are managed via encrypted, HttpOnly cookies that are not accessible to client-side JavaScript.

Password Requirements

• Minimum 8 characters (enforced for password changes)
• At least one uppercase letter required
• At least one numeric digit required
• Passwords validated on both client and server

Password Protection

• Hashing: bcrypt with 10 salt rounds (adaptive cost function)
• Legacy protection: Non-bcrypt passwords are rejected at login — users must complete a secure password reset
• Rate limiting: Authentication endpoints are rate-limited per IP to prevent brute-force attacks
• Session security: Cookies are configured with secure, httpOnly, and sameSite attributes
• Session expiry: Sessions expire after 7 days of inactivity

SSO

Single Sign-On (SSO) is not currently offered. All users authenticate directly via username/email and password. SSO integration (SAML, OIDC) is on the product roadmap for enterprise accounts.

GenAIPI follows key management best practices appropriate to our infrastructure:

API Keys & Secrets

• Rotation: API keys and secrets are rotated when there is any indication of compromise, when personnel with access leave the organization, and periodically as part of security hygiene.
• Scope limitation: Each API key is scoped to the minimum permissions required for its function.
• Separation: Production and development/test keys are strictly separated. Development environments never use production credentials.

Session Secrets

The session signing secret is a high-entropy random string stored as an environment variable. It is unique per environment and rotated if compromise is suspected.

Webhook Secrets

Webhook endpoints use signature verification with dedicated signing secrets. All webhook payloads are cryptographically verified before processing — there is no fallback to unverified payload processing.

TLS Certificates

TLS certificate management (issuance, renewal, revocation) is handled automatically by our hosting infrastructure, ensuring certificates are always valid and up-to-date.

GenAIPI's infrastructure is organized into distinct security zones:

• Production environment: Hosts the live application serving customers. Strictly controlled deployment process. Environment variables and secrets are unique to production.
• Development environment: Fully isolated from production. Uses separate database instances and functionally inert credentials. No access to production data.
• Database isolation: Production databases are not directly accessible from the public internet. Connections are restricted to authorized application servers over SSL-encrypted channels.
• Third-party service isolation: All external service integrations use dedicated, environment-specific credentials. Webhook endpoints validate cryptographic signatures to prevent unauthorized payloads.

We maintain clear separation between environments, enforce least-privilege access, and ensure that production credentials and data are never accessible from development contexts.

Current Status

GenAIPI does not currently hold FIPS 140-2 or FIPS 140-3 certification. Our platform is not configured to operate in FIPS mode, and we do not currently serve federal government clients that require FIPS-validated cryptographic modules.

Current Cryptographic Posture

While not FIPS-certified, GenAIPI uses industry-standard cryptographic implementations:

• TLS 1.2 and TLS 1.3 for data in transit (managed by hosting infrastructure)
• AES-256 for data at rest (managed by database provider)
• bcrypt for password hashing (adaptive cost function)
• Platform-native cryptographic modules for general cryptographic operations

FIPS Roadmap

Should GenAIPI pursue federal contracts or clients requiring FIPS compliance, we would implement: FIPS-validated OpenSSL modules, FIPS-mode enforcement on the application runtime and cloud infrastructure, CMVP-listed cryptographic libraries, and ongoing compliance monitoring for cryptographic library updates and system patches. This work would be scoped and prioritized based on specific federal client requirements.

GenAIPI uses industry-standard cryptographic implementations for all security-sensitive operations:

None of the above currently hold individual FIPS 140-2 or 140-3 validation certificates (CMVP listings). See Section 20 for our FIPS compliance roadmap.

Algorithm

All user passwords are hashed using bcrypt with a work factor of 10 salt rounds. Bcrypt is an adaptive hash function based on the Blowfish cipher, designed specifically for password storage. The cost factor makes brute-force attacks computationally expensive.

Security Measures

• Plaintext passwords are never stored or logged
• Each password hash includes a unique, randomly generated salt
• Legacy accounts with non-bcrypt password hashes are blocked from login and must complete a secure password reset flow
• Password comparison is performed using bcrypt's constant-time comparison function to prevent timing attacks
• Failed login attempts are rate-limited to prevent brute-force attacks

GenAIPI retains customer data only as long as necessary to fulfill the purposes for which it was collected, comply with legal obligations, and support legitimate business needs. Specific retention periods:

Database backups follow the same retention schedule as primary data. Backup retention does not extend data availability beyond the primary retention period.

GenAIPI provides secure data deletion upon contract termination, user request, or data expiration.

User-Initiated Deletion

Users may request deletion of their personal data by contacting privacy@genaipi.org. Upon verification of identity, we process deletion requests within 30 days. Deletion covers all personal data, assessment records, course progress, and certificates associated with the account.

Contract Termination

Upon termination of an enterprise engagement, consulting contract, or software development agreement, all client data is securely deleted within 90 days unless a different timeline is specified in the agreement. System access credentials provided during the engagement are deleted immediately upon completion.

Deletion Methods

• Database records: Permanent deletion from PostgreSQL using secure delete operations. Deleted records are not recoverable.
• Backups: Deleted data is purged from backups as backup rotation cycles complete (within the backup retention window).
• Expired session data: Automated cleanup routines purge expired sessions, password reset tokens, and transient data on a continuous basis.

Exceptions

Certain data may be retained beyond deletion requests where required by law (e.g., financial transaction records for 7 years per regulatory requirements). Users are notified of any such exceptions.

GenAIPI provides clients with evidence of data deletion upon request.

Certificate of Destruction

Upon completion of a data deletion request (whether user-initiated, contract termination, or service decommissioning), clients may request a Certificate of Destruction that documents:

• The scope of data deleted (data types and categories)
• The date deletion was completed
• The method of deletion used
• Confirmation that backup copies have been or will be purged within the backup retention cycle
• Any data retained due to legal or regulatory obligations, with justification

To request a Certificate of Destruction, contact privacy@genaipi.org.

In the event of service decommissioning, end-of-life, or contract termination requiring complete data purging, GenAIPI follows a structured process to ensure all customer data is securely and completely removed.

Procedures

1. Data inventory: A complete inventory of all customer data is compiled, including primary database records, backup copies, log files, and any data held by third-party subprocessors.
2. Primary data deletion: All customer data in primary storage is permanently deleted using secure delete operations.
3. Backup purging: Backup copies containing customer data are identified and securely purged. For encrypted backups, cryptographic wiping (destroying encryption keys) is used where applicable, rendering the data irrecoverable.
4. Third-party notification: Third-party subprocessors are instructed to delete any customer data held on GenAIPI's behalf, in accordance with our data processing agreements.
5. Verification: Deletion is verified through database queries confirming removal and review of backup systems confirming purge completion.

Timelines

• Primary data: Deleted within 30 days of decommissioning decision or contract termination.
• Backup data: Purged within 90 days (aligned with backup rotation cycles).
• Third-party data: Deletion confirmed within 30 days of notification to subprocessors.

Evidence Provided to Clients

Clients receive a Certificate of Destruction upon completion of the decommissioning process, documenting the scope, methods, timelines, and confirmation of complete data removal. See Section 25 for details.

GenAIPI classifies all data handled by our services into defined categories, each with specific access restrictions and minimum security controls. This matrix governs how data is stored, transmitted, accessed, and disposed of across all platforms.

Payment Data

GenAIPI does not store, process, or transmit raw payment card data (PAN, CVV, expiration). All payment data is handled exclusively by our PCI DSS Level 1 certified payment processor and is classified outside the scope of this matrix. GenAIPI receives only transaction confirmation metadata (amounts, dates, status) which is classified as Confidential.

Classification Review

Data classifications are reviewed annually or when new data types are introduced to the platform. Reclassification requires approval from the CAIO. Any data type not explicitly listed defaults to the Confidential classification until formally assessed and categorized.

Cross-Reference

This classification matrix is enforced across all security controls documented in this Trust Center, including access control (Section 15), secret management (Section 16), authentication (Section 17), data retention (Section 23), data deletion (Section 24), and service decommissioning (Section 26).

Version 1.0 — Effective July 21, 2026. This DPA is executed offline; contact security@genaipi.org to countersign or discuss terms.