1. Security approach
Generic-development programs can contain commercially sensitive RLD analyses, formulation hypotheses, analytical methods, manufacturing information, BE planning, quality evidence, and regulatory strategy. BayesPK Generics is built so that those materials can be organized and reviewed without turning a public product demo into a place for confidential data.
Important boundary: public labeled demos use illustrative content. Do not enter confidential CMC, patient, supplier, study, or submission information into public forms or demonstrations unless your organization has an appropriate approved workspace and agreement.
2. Data protection
Data exchanged between a browser and BayesPK services is protected using industry-standard transport encryption (TLS).
Customer content held in supported platform databases and object storage uses the standard encryption capabilities of the underlying infrastructure providers.
Customer content is designed to remain logically separated by organization and workspace so one team's controlled evidence is not exposed to another.
Confidential customer inputs are not intended to be reused to answer another customer's questions or surfaced in another customer's output.
3. Access and accountability
Access should reflect the responsibilities of a generic-development team. BayesPK Generics supports role-aware workspace access and review workflows so that formulation, analytical, manufacturing, BE, quality, regulatory, and program users can work from the same evidence spine without every user having the same permissions.
- Role-based access: users should see only the organization and workspaces appropriate to their role.
- Named reviewer context: review, sign-off, evidence-locking, and packet decisions can retain a named user and role context.
- Least privilege: internal operational access is limited to what is required to operate and support the service.
- Revocable access: workspace and API access can be removed when a user, team, or integration no longer requires it.
4. Evidence integrity and controlled outputs
Security for Generics is also about keeping the development argument intact. A filing package should not lose the connection between source posture, QTPP/CQAs, formulation choices, methods, dissolution or BE evidence, reviewer conditions, and the resulting decision.
Workspaces are designed to retain source, owner, confidence, version, and review context rather than only a detached conclusion.
Board packs, reports, and filing-support outputs are intended to preserve the decision trail and their preparation context.
Evidence movement, open conditions, and review state should be visible before a packet is treated as ready.
The product supports preparation and review; qualified CMC, QA, BE, regulatory, and legal authorities retain final responsibility.
5. Platform security practices
- Secure development practices, including review before production changes.
- Dependency monitoring and remediation of known third-party component vulnerabilities.
- Separation of development, staging, and production environments.
- Application and infrastructure logging to support operational monitoring and investigation.
- Hosting on established cloud infrastructure providers with their own physical and infrastructure-level controls.
Customer-specific architecture, integration, data residency, recovery, and security-control requirements should be agreed before regulated or sensitive production use.
6. Continuity and recovery
BayesPK maintains backups and platform configuration safeguards intended to support recovery from common failure scenarios. Recovery-point and recovery-time objectives, retention expectations, and customer-specific export or archival requirements should be documented for an enterprise deployment.
7. Life-sciences alignment
BayesPK Generics is designed with GxP-aware and data-integrity-aware practices in mind: attributable review context, timestamps, evidence linkage, controlled outputs, and visible open conditions. This is design intent—not a claim of a particular third-party certification, validation status, or regulatory acceptance. Each organization remains responsible for intended-use assessment, validation, SOPs, and applicable regulatory obligations.
Where relevant, customers can assess deployment requirements against expectations such as data-integrity principles, 21 CFR Part 11–aware controls, ICH quality guidance, and their own quality-management system.
8. Incident response and responsible disclosure
We maintain an internal process to triage, investigate, and remediate security incidents. Where a confirmed incident affects customer content in a way that requires notification under applicable law or a customer agreement, affected customers will be notified without undue delay in accordance with those obligations.