Trust Center: Security, Privacy & Compliance at Practical AI Institute

1. Information Security Risk Management Program

Practical AI Institute 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.

2. Confidentiality & Acceptable Use Agreement

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

Practical AI Institute — Confidentiality and Acceptable Use Agreement

This Confidentiality and Acceptable Use Agreement ("Agreement") is entered into by and between Practical AI Institute ("Company") and the undersigned individual ("Personnel"), effective as of the date of signature.

1. Definitions

"Confidential Information" means all non-public information disclosed to or accessed by Personnel in connection with their role, including but not limited to: customer data, personal information, assessment results, certification records, business strategies, proprietary methodologies, source code, API keys, credentials, financial data, and any information marked or reasonably understood to be confidential.

"Company Systems" means all hardware, software, networks, applications, databases, cloud services, email accounts, and other technology resources provided by or accessible through Practical AI Institute.

2. Confidentiality Obligations

Personnel shall: (a) hold all Confidential Information in strict confidence; (b) not disclose Confidential Information to any third party without prior written authorization; (c) use Confidential Information solely for performing authorized job duties; (d) return or securely destroy all Confidential Information upon termination of engagement; (e) immediately report any suspected or actual unauthorized disclosure.

3. Acceptable Use of Company Systems

Personnel shall: (a) use Company Systems only for authorized business purposes; (b) not install unauthorized software or hardware on Company Systems; (c) not attempt to circumvent security controls, access controls, or monitoring systems; (d) not share login credentials or access tokens with any other person; (e) use strong, unique passwords and enable multi-factor authentication where available; (f) lock or secure devices when unattended; (g) not transmit Confidential Information over unsecured channels; (h) not connect untrusted external storage devices to Company Systems.

4. Data Handling

Personnel shall: (a) access only the minimum data necessary for their role; (b) not copy, download, or export customer data except as required for authorized tasks; (c) store data only in approved, encrypted locations; (d) securely delete or return data when no longer needed; (e) not use customer data for personal purposes, demonstrations, or training without explicit authorization.

5. Device Security

Personnel shall: (a) use full-disk encryption on all devices used to access Company Systems; (b) keep operating systems, browsers, and security software up to date; (c) use a VPN when accessing Company Systems from public or untrusted networks; (d) immediately report lost, stolen, or compromised devices.

6. Incident Reporting

Personnel shall immediately report to the CAIO or designated security contact any: (a) suspected or confirmed security breach; (b) unauthorized access to data or systems; (c) loss or theft of devices containing Confidential Information; (d) phishing attempts, malware, or suspicious activity; (e) violations of this Agreement by any person.

7. Consequences of Violation

Violation of this Agreement may result in: (a) immediate termination of employment or contract; (b) revocation of system access; (c) legal action for breach of contract, misappropriation of trade secrets, or violation of applicable data protection laws; (d) obligation to indemnify Practical AI Institute for damages resulting from the violation.

8. Survival

The confidentiality obligations in this Agreement survive termination of the Personnel's engagement with Practical AI Institute for a period of three (3) years, or indefinitely with respect to trade secrets as defined by applicable law.

9. Acknowledgment

By signing below, Personnel acknowledges that they have read, understand, and agree to be bound by all terms of this Agreement. Personnel further acknowledges that they have received adequate training on Practical AI Institute's security policies and acceptable use requirements.

3. Incident Response Policy

Practical AI Institute 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 Practical AI Institute 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.

4. Incident Response Program — Client Notification & SLAs

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.

5. Network Vulnerability Management

Practical AI Institute 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.

6. Encryption Standards

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

Practical AI Institute 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.

7. Communication Protocols

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.

8. Network Ports & Restrictions

Practical AI Institute'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.

9. Application Vulnerability Management

Practical AI Institute 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.

10. Patch Management

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.

11. End-of-Life (EOL) Software Policy

Practical AI Institute 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.

12. Internal Audits

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.

13. Web Application Security Controls

Practical AI Institute implements multiple layers of defense to mitigate web application vulnerabilities:

Note on WAF: Practical AI Institute 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.

14. Secure Development Practices

Secure Software Development Lifecycle (SSDLC)

Practical AI Institute 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.

15. Roles & Permissions

Practical AI Institute 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.

16. Secret Management

Practical AI Institute 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).

17. Authentication

Authentication Method

Practical AI Institute 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.

18. Key Management

Practical AI Institute 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.

19. Network Segmentation

Practical AI Institute'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.

20. FIPS Compliance

Current Status

Practical AI Institute 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, Practical AI Institute 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 Practical AI Institute 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.

21. Cryptographic Libraries

Practical AI Institute 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.

22. Password Hashing

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

23. Data Retention Policy

Practical AI Institute 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.

24. Data Deletion Procedures

Practical AI Institute 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 contact@practicalaiin.com. 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.

25. Evidence of Data Deletion

Practical AI Institute 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 contact@practicalaiin.com.

26. Service Decommissioning & Data Purging

In the event of service decommissioning, end-of-life, or contract termination requiring complete data purging, Practical AI Institute 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 Practical AI Institute'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.

27. Data Classification Matrix

Practical AI Institute 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

Practical AI Institute 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. Practical AI Institute 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).

Questions?

For security-related inquiries, audit requests, or to request access to detailed security reports, please contact us at contact@practicalaiin.com.

Frequently Asked Questions

What security standards does Practical AI Institute follow?

Practical AI Institute maintains a documented security program aligned to SOC2 principles, covering information security risk management, encryption, authentication and access control, data retention and deletion, and incident response. HIPAA-compatible data segmentation is applied where a client engagement requires it.

How is data encrypted?

Data is encrypted with AES-256 at rest and TLS 1.2 or higher in transit. The platform is not configured to operate in FIPS mode, and its current cryptographic implementations do not hold FIPS validation certificates.

How is data classified?

Every data type is assigned a classification in the data classification matrix documented in this Trust Center. Any data type not explicitly listed defaults to Confidential until it is formally assessed and categorized.

How do I request a security report or an audit?

Email contact@practicalaiin.com for security-related inquiries, audit requests, or to request access to detailed security reports.

Related

The governance principles behind these controls are set out in the Practical AI Doctrine. To see how they are applied inside a real engagement, see the Strategic AI Assessment. For who we are and how we work, see About Practical AI Institute.