Security

Proxhr Security Policy / Security Overview

Effective Date: December 15, 2025 Last Updated: December 15, 2025

Security Program Overview
Security Framework Alignment
Data Protection
Access Control
Secure SDLC
Vulnerability Management
Monitoring & Logging
Incident Response
Business Continuity & Disaster Recovery
Vendor / Subprocessor Security
Privacy-by-Design & Data Minimization
Physical Security
Compliance & Assurance
Customer Responsibilities
Changes to This Policy
Contact Us

1. Security Program Overview

Proxhr, Inc. (“Proxhr”) provides a B2B SaaS platform for verification of employment and income (“VOE/VOI”). The Services may process sensitive information including employment status, compensation/income data, and certain identifiers. This Security Policy describes our security program at a high level for customer due diligence and procurement reviews.

1.1 Program goals

Our security program is designed to:

Protect the confidentiality, integrity, and availability of customer and Consumer data.
Reduce the likelihood and impact of unauthorized access, disclosure, alteration, or loss.
Support Customers’ security and compliance requirements through appropriate safeguards, transparency, and contractual commitments.
Improve over time through monitoring, testing, and lessons learned.

1.2 Governance and accountability

Security ownership: Security Team is responsible for the security program, with support from engineering and operations leadership.
Risk-based approach: We assess risks based on the sensitivity of data, system exposure, credible threat scenarios, and business impact. Controls are prioritized to address higher-risk areas first.
Policies and standards: Proxhr maintains internal policies addressing topics such as access control, acceptable use, secure development, incident response, and vendor management.
Training and awareness: Personnel with access to Proxhr systems receive security awareness guidance appropriate to their role.
Continuous improvement: We review incidents, near-misses, and security findings to improve processes and controls.

1.3 Personnel security

Proxhr uses personnel security practices intended to reduce insider risk:

Confidentiality obligations are required for personnel and contractors with access to Proxhr systems.
Access is provisioned based on role and removed promptly during offboarding.
Privileged access is restricted and subject to heightened controls (see Section 4).
Security expectations (e.g., device protection, password/2FA requirements, acceptable use) are enforced through internal policy.

1.4 Scope and limitations of this document

This document is an external-facing overview. It intentionally excludes sensitive details such as network diagrams, IP ranges, and exact vendor configurations. Detailed evidence (where available) may be shared with customers under NDA or through a trust portal (see Section 13).

2. Security Framework Alignment

Proxhr’s security program is designed to align with common SaaS security expectations and can be mapped to well-known frameworks.

2.1 SOC 2 / Trust Services Criteria alignment (high level)

Proxhr’s controls are designed to support outcomes consistent with SOC 2 Trust Services Criteria categories, including:

Security: protection against unauthorized access and misuse
Availability: uptime and resiliency practices
Confidentiality: safeguards for confidential data
Processing Integrity: controls that support accurate and complete processing
Privacy: privacy-aligned handling practices (see our Privacy Policy)

Security standards/reports: TODO.

2.2 NIST CSF 2.0 function mapping (high level)

Our security program addresses the NIST CSF functions as follows:

Govern: security ownership, policies, risk management, vendor oversight
Identify: awareness of assets, data, and key risks
Protect: access control, encryption, secure development, data minimization
Detect: logging, monitoring, alerting, anomaly detection
Respond: incident response process and communications
Recover: backups, restoration testing, continuity planning

2.3 Control themes customers can expect

Regardless of framework, customers can expect Proxhr to focus on:

Least privilege access and strong authentication
Encryption and secure key management principles
Security logging, monitoring, and incident response readiness
Secure development and change management
Vendor due diligence and data minimization

3. Data Protection

3.1 Data classification and handling

Proxhr treats employment and income verification data (“Verification Data”) as confidential. We also treat certain categories as “Sensitive” due to higher risk if exposed (such as income and government identifiers). Handling expectations include:

Restricting access to authorized users and systems.
Logging and monitoring access to sensitive systems.
Minimizing exposure of sensitive information in logs and monitoring payloads.
Applying retention limits and deletion controls consistent with contracts and law.

3.2 Encryption in transit

Proxhr uses TLS to encrypt data in transit between clients, browsers, APIs, and our servers.
We aim to use modern TLS configurations and disable insecure protocols and ciphers where feasible.
Customer integrations should use HTTPS/TLS endpoints and validate certificates.

3.3 Encryption at rest

Proxhr encrypts data at rest within our AWS environment, including data stored in managed databases and storage services, using cloud-native encryption capabilities and/or application-level encryption where appropriate.
Backups are also protected through encryption and access controls.

3.4 Key management principles

Proxhr’s key management practices are designed to reduce the risk of unauthorized key use or disclosure:

Keys are protected using access controls and least-privilege principles.
Key access is limited to authorized systems and personnel.
Key rotation and lifecycle management are implemented based on risk and operational needs.
We use secure secrets handling practices and do not intentionally hardcode secrets in source code.
Access to key material and secrets is logged to support accountability.

3.5 Data segregation and tenant isolation

Proxhr is designed as a SaaS platform. Tenant isolation is implemented through logical access controls at the application and data layers, such that one customer’s users cannot access another customer’s data through normal application operations.

Deployment model: TODO (confirm whether Proxhr is multi-tenant only, offers single-tenant options, or supports customer-dedicated environments).

3.6 Data retention and deletion

Proxhr follows data minimization and retention principles:

Default retention: TODO.
Data is retained only as long as needed for verification, support, compliance, and security purposes.
Deletion and de-identification processes take into account legal obligations, dispute support needs, and backup cycles.

3.7 Data export and portability (customer-facing)

Customer access to data depends on product configuration and contractual terms. Where applicable, Proxhr supports:

Controlled export of verification logs or reports for auditing and compliance purposes.
Secure delivery mechanisms for reports and data exports.
Role-based restrictions on who can export or download data.

Export features: TODO (describe product functionality and controls if available).

3.8 Data integrity and processing safeguards

Because Proxhr supports employment and income verification workflows, integrity is as important as confidentiality. Our safeguards are designed to help ensure that verification results are attributable and that changes are traceable. Examples of integrity-focused controls include:

Validation of required fields and structured inputs in verification workflows.
Audit trails for key actions such as request creation, authorization capture, data retrieval, and result delivery.
Controls intended to prevent accidental overwrites and unauthorized modifications to verification records.
Separation of duties and approvals for higher-risk administrative changes where practical.

Proxhr’s goal is to provide verifications that are reproducible and explainable: if a Customer or Consumer questions a verification outcome, we can trace when the request occurred, who initiated it, what sources were used, and what data was returned.

3.9 Data minimization in logs and telemetry

Operational telemetry (logs, traces, and error reports) is necessary to secure and operate a SaaS platform, but it can also create privacy and security risks if it captures sensitive fields. Proxhr therefore aims to:

Log identifiers and request IDs instead of full sensitive values where feasible.
Mask or redact sensitive fields (such as government identifiers) in application logs and error payloads.
Restrict access to logs and monitoring systems to authorized personnel.
Apply retention limits and deletion processes to logs consistent with security investigation needs.

3.10 Network and platform protections (high level)

Proxhr leverages AWS capabilities and standard SaaS patterns to reduce exposure and segment access. Without disclosing sensitive architecture details, typical safeguards include:

Cloud network segmentation controls (e.g., virtual networking and security groups) to limit access paths.
“Default deny” posture for inbound connections, exposing only necessary services.
Use of managed cloud services to reduce operational risk (e.g., managed databases, storage, and identity controls).
Periodic review of cloud configuration and IAM permissions on a risk-based basis.

These controls are intended to reduce the attack surface and to help ensure that only authorized traffic reaches sensitive systems.

4. Access Control

4.1 Identity and access management fundamentals

Proxhr’s access controls are designed to ensure that only authorized people and systems can access sensitive functions and data. Core practices include:

Strong authentication and secure session handling.
Least privilege access policies.
Role-based access control (RBAC) for application permissions.
Logging of key access and administrative actions.

4.2 Least privilege and role-based access

Access to systems and data is granted based on job function and business need (“least privilege”).
Administrative access to production systems is restricted to authorized personnel.
Access is reviewed and adjusted when roles change.
Privileged access is time-limited where practical and used only when necessary.

4.3 Authentication (2FA / SSO)

2FA/MFA: Proxhr supports 2FA for user accounts, especially for administrative access and sensitive operations.
SSO/SAML: TODO (if SSO/SAML is offered, specify availability and requirements).
Password expectations: We encourage strong passwords and may enforce minimum length/complexity requirements and protection against common compromised passwords.

4.4 Administrative controls and support access

Privileged administrative functions are restricted and logged.
Support personnel access to customer data is limited to what is necessary to resolve support tickets and is governed by authorization workflows.
We use “need to know” principles for internal troubleshooting.
Where practical, we use separate admin tooling and audit trails for elevated actions.

4.5 API security

Where Proxhr provides APIs:

Authentication uses secure credentials (e.g., API keys or tokens; OAuth support: TODO if applicable).
API credentials are unique per customer and intended to be treated as secrets.
Rate limits and abuse protections are used to reduce automated misuse and scraping.
API requests and administrative actions are logged for security and troubleshooting.
Customers are expected to protect their API credentials, restrict who can access them, and rotate them if compromise is suspected.

4.6 Customer administrative features

Where supported, Proxhr may offer customer administrators the ability to:

Create, modify, and deactivate Authorized User accounts.
Assign roles/permissions.
Review audit activity.
Configure authentication or integration settings.

Customer admin features: TODO (describe what is available at launch).

4.7 Account lifecycle management

Account lifecycle controls are intended to reduce the risk of unauthorized access over time:

Provisioning: Customer administrators (or Proxhr, depending on setup) create Authorized User accounts with appropriate roles.
Changes: Role and permission changes are logged.
Deprovisioning: Access is removed when a user no longer needs it (e.g., job change or termination).
Recovery: Account recovery and password reset processes are designed to require control of a verified communication channel and to limit abuse.

4.8 Session security

Proxhr uses standard web and API session protections appropriate for a SaaS platform, which may include:

Secure session tokens and protections against session fixation.
Protection against CSRF where applicable to browser-based flows.
Session timeout behavior appropriate to risk (timeouts and reauthentication requirements may differ for administrative actions).
Monitoring for repeated failed logins and abuse patterns.

Session controls: TODO (document specific timeouts or lockout thresholds if you wish to make external commitments).

4.9 Support access and customer data handling

When Customers request support, Proxhr may need to access limited information to troubleshoot issues. Our objective is to do so safely:

We encourage Customers to avoid sending Sensitive Personal Information in support tickets unless necessary.
Proxhr limits internal support access to the minimum necessary to resolve the issue.
Where feasible, we use metadata and request identifiers rather than full record content.
Any elevated troubleshooting access is subject to logging and oversight.

Customers can help by providing request IDs, timestamps, and screenshots that avoid exposing unnecessary personal data.

5. Secure SDLC

Proxhr applies secure software development lifecycle (SDLC) practices intended to reduce the introduction of vulnerabilities and limit risk from changes.

5.1 Secure design and review

Security considerations are incorporated during feature design, particularly for features handling Sensitive Personal Information or external integrations.
Higher-risk features may receive additional review, including threat modeling or abuse-case review on a risk-based basis.
Data minimization and least-privilege principles are applied in design.

5.2 Code review and CI/CD controls

Changes to application code are subject to peer review.
CI/CD pipelines include automated checks appropriate to the codebase (e.g., tests, linting, and security checks where feasible).
Production deployments are controlled and auditable.
Rollback procedures are used to reduce impact from problematic changes.

5.3 Secure coding practices

Proxhr’s secure coding expectations include:

Input validation and output encoding to reduce injection risks.
Strong authentication and authorization checks for sensitive endpoints.
Protection against common web vulnerabilities (e.g., CSRF, SSRF, XSS) based on the application context.
Proper error handling to avoid exposing sensitive data.
Security-focused logging that avoids logging Sensitive PI where feasible.

5.4 Dependency and supply-chain security

Proxhr monitors third-party dependencies and applies updates based on risk.
Critical security updates are prioritized.
We avoid adding dependencies that are not necessary for business functionality.
SBOM: TODO (if a software bill of materials is produced or available upon request).

5.5 Secrets management

Secrets (API keys, tokens, credentials) are stored and managed in secure systems rather than source code.
Access to secrets is restricted and logged.
Secrets are rotated when compromise is suspected and as part of lifecycle management.

5.6 Environment separation and data handling

Production, staging, and development environments are separated.
Access to production is more restricted than access to lower environments.
Production data is not used in non-production environments except where necessary and with appropriate safeguards (e.g., masking or limited subsets), consistent with customer agreements and privacy commitments.

5.7 Infrastructure and cloud configuration management

Proxhr operates on AWS. Cloud security is managed through a combination of AWS controls and Proxhr configuration and process controls. Depending on the component, these practices may include:

Managing cloud permissions using role-based identity controls and least privilege.
Reviewing infrastructure changes through code review or change approval processes (for example, where infrastructure is managed as code).
Using separate accounts/projects/environments to reduce blast radius and accidental cross-environment access.
Protecting administrative interfaces and restricting access to management consoles.

Infrastructure-as-code: TODO (confirm whether IaC is used and describe at a high level).

5.8 Security testing during development (risk-based)

In addition to peer review and automated tests, Proxhr may use security testing practices such as:

Automated scanning of dependencies and containers.
Static analysis for common patterns of insecure code where feasible.
Targeted manual review of high-risk changes (e.g., new authentication flows, permissions changes, or sensitive data handling).
Review of error handling to reduce inadvertent exposure of Sensitive PI.

The goal is not to claim perfect security, but to detect and address common classes of vulnerabilities before they reach production.

6. Vulnerability Management

6.1 Vulnerability discovery and assessment

Proxhr uses a risk-based approach that may include:

Automated scanning of dependencies (SCA) and repositories.
Static analysis (SAST) and/or configuration checks where feasible.
Infrastructure and cloud configuration review on a risk-based basis.
Manual security review for higher-risk changes or features.

6.2 Patching and remediation

We prioritize remediation based on severity, exploitability, and exposure:

Critical issues are addressed as soon as practicable based on risk.
High and medium issues are addressed on a planned basis, considering compensating controls and business impact.
Low-risk issues may be addressed during regular maintenance cycles.

Patching SLAs: TODO (define target timeframes if you wish to commit externally).

6.3 Penetration testing and independent review

Penetration testing cadence: TODO (e.g., annually or periodically, and whether performed by a third party).
We may perform additional testing after major architectural changes.
Findings are tracked and remediated based on risk.

6.4 Vulnerability disclosure and safe harbor

We welcome responsible security research.

Report vulnerabilities to security@Proxhr.com with sufficient detail to reproduce the issue.
Do not access, modify, or exfiltrate data that does not belong to you.
Do not perform denial-of-service tests against the Services.
We will acknowledge reports and work with you on a reasonable timeline for validation and remediation.

Bug bounty program: TODO (if applicable).

6.5 Tracking and verification of remediation

Security findings are most valuable when they result in verified fixes. Proxhr tracks vulnerabilities and remediation work to closure, which typically includes:

Documenting the issue, severity rationale, and affected components.
Assigning an owner and target remediation plan based on risk.
Verifying that remediation is effective (e.g., through re-scans, tests, or code review).
Documenting exceptions or compensating controls when immediate remediation is not feasible.

For customer-reported issues, we may provide status updates and, where appropriate, a summary of the resolution and preventive measures.

7. Monitoring & Logging

7.1 Logging principles

Proxhr uses logging and monitoring controls designed to detect anomalous behavior and support incident response. Our logging practices are guided by these principles:

Log what is necessary for security and reliability (authentication events, admin actions, API requests, and errors).
Avoid logging Sensitive Personal Information unless required for troubleshooting and then restrict access appropriately.
Protect logs from unauthorized access and tampering to the extent practicable.
Retain logs for a period sufficient to support investigations and compliance needs (retention is risk-based).

7.2 Monitoring and alerting

We use monitoring to detect availability issues, error spikes, and suspicious patterns.
Alerts are configured to route to operational responders for investigation and triage.
We leverage cloud-native monitoring capabilities as part of our AWS deployment.

7.3 Application monitoring (Sentry)

Proxhr uses Sentry for application monitoring and error tracking. Sentry is configured to support troubleshooting and reliability while minimizing unnecessary collection of Personal Information in error payloads. Where feasible, sensitive fields are excluded or masked.

7.4 Audit logs (customer visibility)

Proxhr maintains audit trails for key system and administrative actions. Customer-facing audit logs: TODO (describe whether audit logs are available in the product, what they include, and retention/immutability controls).

7.5 Log retention, protection, and time synchronization

To support investigations and auditing, Proxhr aims to maintain logs with appropriate retention and integrity protections:

Retention: log retention is set based on risk, balancing investigation needs with data minimization. (Exact durations: TODO if you wish to publish.)
Integrity: access to logs is restricted, and logs are protected from unauthorized modification to the extent practicable.
Time synchronization: systems are configured to use reliable time sources so events can be correlated across components during incident response.

Where Customers require evidence of logging controls or retention practices, Proxhr can discuss under NDA as appropriate for the request.

8. Incident Response

Proxhr maintains an incident response process intended to enable timely detection, containment, eradication, and recovery from security incidents.

8.1 Incident lifecycle

Our process generally includes:

Detection and triage: identify a suspected incident and assess scope and severity.
Containment: limit further impact (e.g., isolate systems, revoke credentials, disable access pathways).
Eradication and remediation: remove root cause (e.g., patch, configuration changes, key rotation).
Recovery: restore normal operations and validate controls.
Post-incident review: document lessons learned, root cause, and preventive improvements.

8.2 Incident classification

Incidents are prioritized based on factors such as:

Impact on confidentiality, integrity, or availability.
Type and sensitivity of data involved.
Scope of affected systems and customers.
Evidence of malicious activity or exploitation.

8.3 Communications and notification

Proxhr’s incident notification commitments are governed by law and contract.

Incident notification commitments: TODO (per contract and applicable law)
If Proxhr becomes aware of a security incident that materially affects customer data, we will notify impacted customers consistent with contractual requirements and applicable law, and provide information reasonably necessary for customers to meet their own obligations (e.g., incident description, timeframe, affected systems, and mitigation steps).

8.4 Evidence preservation and post-incident improvements

Proxhr may preserve relevant logs and evidence needed for investigation and legal compliance. After significant incidents, we perform a post-incident review to improve controls, monitoring, and processes.

8.5 Testing, tabletop exercises, and coordination

Proxhr’s ability to respond effectively depends on practice and coordination:

We review and improve incident response playbooks based on lessons learned.
We may conduct tabletop exercises on a periodic, risk-based basis to test decision-making, communications, and recovery steps.
We coordinate incident communications through designated channels to reduce confusion and ensure accurate messaging.
We preserve evidence in a manner intended to support root-cause analysis and, where needed, customer or legal requirements.

Tabletop cadence: TODO (if you wish to publish a target frequency).

9. Business Continuity & Disaster Recovery

Proxhr designs for service resilience and maintains business continuity practices appropriate for a SaaS provider.

9.1 Backups and restoration

We use backups of critical data and systems within our AWS environment.
Backups are protected using encryption and access controls.
Restoration procedures are tested periodically on a risk-based basis.

9.2 RPO and RTO

RPO (Recovery Point Objective): TODO
RTO (Recovery Time Objective): TODO

9.3 Resilience and recovery design

We leverage AWS capabilities to support availability, redundancy, and recovery.
We plan for recovery from common failure scenarios (e.g., system misconfiguration, accidental deletion, infrastructure outages) using layered controls.

9.4 Business continuity planning

In addition to technical recovery controls, Proxhr maintains business continuity considerations appropriate for a startup-stage SaaS provider, which may include:

Identification of critical services and dependencies (e.g., cloud infrastructure, DNS, monitoring).
On-call or escalation expectations for critical incidents.
Documentation of restoration steps and key contacts.
Periodic review of continuity assumptions as the product and customer base grow.

Proxhr’s continuity posture is designed to improve over time. Customers with specific continuity requirements should raise them during contracting so we can align expectations.

10. Vendor / Subprocessor Security

Proxhr uses third-party service providers to operate the Services. We evaluate vendors based on risk, data access, and the criticality of the service.

10.1 Vendor due diligence

We assess vendor security and privacy posture appropriate to the risk (e.g., reviewing documentation, contractual commitments, and public attestations where available).
We limit vendor access to the minimum necessary to provide the service.
We expect vendors to maintain appropriate safeguards and to notify Proxhr of security incidents affecting our data, consistent with contract.

10.2 Current core vendors (launch stage)

At launch, Proxhr’s third-party processing is limited to:

Amazon Web Services (AWS) – cloud hosting and infrastructure
Sentry – application monitoring and error tracking

Other than these core providers, Proxhr does not use additional subprocessors for core Verification Data processing. If this changes, we will update our policies and, where required, customer agreements.

10.3 Subprocessor changes and transparency

Proxhr understands that Customers often need visibility into subprocessors for vendor risk management. If Proxhr adds or changes subprocessors that process customer data, we will:

Update our public disclosures (this Security Policy and/or our Privacy Policy).
Provide Customer notice where required by contract.
Ensure that new vendors are subject to appropriate confidentiality, security, and data protection terms.

At launch, Proxhr’s subprocessor footprint is intentionally small to reduce supply-chain risk.

11. Privacy-by-Design & Data Minimization

Security and privacy are connected. Proxhr’s security controls support privacy-by-design principles:

Collect and process only what is needed for authorized verification and platform security.
Restrict access to Sensitive Personal Information and maintain auditability.
Use retention limits and deletion processes consistent with legal and contractual requirements.
Reduce unnecessary exposure of Personal Information in logs and monitoring data.
Support Consumer rights and dispute processes consistent with our Privacy Policy.

For more detail on privacy handling, see our Privacy Policy.

12. Physical Security

Proxhr’s production infrastructure is hosted with AWS. Physical security controls for data centers (e.g., perimeter security, access controls, surveillance, and environmental protections) are managed by AWS as part of its cloud services.

Proxhr’s own office and personnel physical access controls are maintained at an appropriate level for our business operations. Personnel are expected to secure laptops and credentials and to avoid storing sensitive customer data locally except where necessary for support and then only with appropriate safeguards.

12.1 Endpoint and device security (high level)

Proxhr personnel commonly access administrative systems from company-managed or approved devices. Device security expectations include:

Device encryption and screen lock usage.
Keeping operating systems and applications updated with security patches.
Use of anti-malware protections where appropriate.
Secure handling of credentials and secrets (no sharing; no storage in plaintext).

Exact endpoint management tooling is not disclosed publicly for security reasons.

12.2 Remote work considerations

Where personnel work remotely, Proxhr expects secure practices, such as:

Avoiding public or shared computers for administrative tasks.
Using secure networks where possible and avoiding untrusted Wi-Fi for sensitive operations unless protected by appropriate safeguards.
Protecting physical documents and avoiding printing Consumer data unless strictly necessary.

12.3 Media handling

Proxhr’s objective is to avoid storing customer data on removable media. If data must be exported for support or auditing, it should be handled through approved secure methods and retained only as long as necessary.

13. Compliance & Assurance

Proxhr’s compliance and assurance posture evolves with the business. We support customer security reviews through reasonable due diligence.

13.1 Reports and attestations

Available reports/certifications: TODO
Customers may request available assurance artifacts under NDA or through a trust portal: TODO.

13.2 Security questionnaires and customer diligence

We may respond to reasonable security questionnaires, balancing transparency with the need to protect sensitive security details. In some cases we may provide:

High-level descriptions of controls (this document).
Vendor and data flow summaries at an appropriate level.
Evidence summaries (e.g., penetration testing statement, policies) under NDA.

13.3 Security documentation requests

Customers often need security documentation for vendor assessments. Depending on availability and under appropriate confidentiality terms (such as an NDA), Proxhr may provide:

A completed security questionnaire or a summary of controls.
Copies or summaries of relevant internal policies (e.g., incident response, access control) where appropriate.
Evidence of third-party testing or security reviews when available (e.g., a penetration test letter or executive summary).
Vendor/subprocessor summaries and data flow descriptions at a level that does not create additional risk.

Proxhr may also use a trust portal or secure sharing method for distributing sensitive documents: TODO.

13.4 Roadmap and maturity

As an early-stage company, Proxhr’s security and compliance program is designed to scale. Over time, we expect to formalize and expand assurance artifacts (for example, SOC 2 reporting, more frequent independent testing, and more detailed customer-facing controls). Customers with specific assurance requirements should raise them during contracting so we can align expectations and timelines.

14. Customer Responsibilities

Security is a shared responsibility.

In a SaaS environment, responsibilities are shared: Proxhr secures the underlying application, AWS-hosted infrastructure, and operational controls described in this Policy, while Customers secure their own user accounts, endpoints, networks, and internal business processes (including who is authorized to request verifications and how results are used). Clear separation of responsibilities reduces gaps.

Examples:

Proxhr can enforce encryption, logging, and platform access controls, but Proxhr cannot see or enforce your internal approval rules, device management, or employee offboarding.
Customers can enforce least-privilege for their team, control who has access to verification results, and secure API keys, but Customers cannot directly control Proxhr’s underlying cloud configuration and operational monitoring.

Recommended Customer practices include appointing a primary administrator, requiring unique user accounts (no shared logins), reviewing user access and roles periodically, and promptly removing access when personnel change roles or leave. If SSO/SAML is available in your plan, use it to centralize access control; if not, require 2FA and maintain strong password hygiene. Customers should also monitor their own systems for unusual activity and notify Proxhr promptly if compromise is suspected.

If you build or operate integrations with Proxhr, you are responsible for securing those integrations (including secure storage of credentials, restricting which systems and personnel can access them, validating inputs, and handling outputs in accordance with your policies and applicable law).

Maintain strong authentication and enable 2FA where available.
Restrict account access to authorized personnel and promptly remove access when personnel change roles or leave.
Protect API keys and integration credentials; rotate credentials if compromise is suspected.
Configure roles and permissions carefully to prevent overbroad access.
Use verification results only for lawful purposes and in accordance with customer policies and applicable law.
Provide appropriate notices and obtain required Consumer authorizations for verification requests.
Notify Proxhr promptly if you suspect unauthorized access to your account or data.

15. Changes to This Policy

We may update this Security Policy from time to time to reflect changes in our controls, vendors, or legal requirements. We will post the updated version with a new “Last Updated” date.

16. Contact Us

Proxhr, Inc. 330 Crane Ave Ste A Turlock, CA 95380

Security contact: Security Team
Security email (incident/vulnerability reporting): security@Proxhr.com
Security documentation requests: security@Proxhr.com (we may require an NDA before sharing sensitive materials)
Support: support@Proxhr.com
Privacy: privacy@Proxhr.com

Not legal advice: This Security Policy is provided for general informational purposes and does not constitute legal advice. Customers should evaluate their own legal and compliance obligations and consult counsel as needed.

Table of Contents