Security and data protection are built into the SDS platform approach.
SDS is designed to protect buyer and supplier information through controlled access, secure development practices, data governance, operational monitoring, and a disciplined incident-response process.
Explore Our Security App
This page describes the intended SDS security program and should not be interpreted as a claim of certification unless specifically stated.
Security Program Overview
SDS
Access Control
Role-based permissions and least-privilege principles
Data Protection
Encryption, secure handling, and controlled retention
Monitoring
Logging, alerting, and administrative visibility
Response
Defined escalation and incident-management procedures
A layered approach to platform protection.
SDS security is organized around prevention, detection, response, and continuous improvement.
1
Least Privilege
Users and administrators should receive only the access required for their responsibilities.
2
Secure by Design
Security requirements are considered during product design, development, testing, and release.
3
Data Minimization
SDS should collect and retain only the information required to support approved business purposes.
4
Defense in Depth
Multiple technical, operational, and administrative controls reduce reliance on any single safeguard.
5
Traceability
Administrative actions, access events, and material data changes should be logged and reviewable.
6
Continuous Improvement
Security practices should evolve based on testing, incidents, platform growth, and changing risks.
Protecting access, data, and platform operations.
The SDS security program is intended to combine identity, data-protection, infrastructure, application, and operational controls.
Specific production controls should be validated and documented before customer commitments are made.
ID
Identity and Access Management
Role-based access, administrative approval, credential standards, account lifecycle management, and optional enterprise SSO capabilities.
EN
Encryption
Protection of data in transit using modern transport encryption and encryption of stored data where appropriate.
LG
Logging and Monitoring
Administrative activity, access events, workflow changes, and relevant security signals should be logged and monitored.
BK
Backup and Recovery
Defined backup, restoration, recovery-point, and recovery-time practices should support service continuity.
VM
Vulnerability Management
Routine dependency review, patching, technical testing, and remediation prioritization should address known vulnerabilities.
TR
Third-Party Risk
Critical service providers should be evaluated for security, privacy, reliability, and contractual protections.
Security throughout product development.
Security should be integrated into the full software lifecycle rather than added after development is complete.
1
Design
Identify sensitive data, user roles, abuse cases, access requirements, and security dependencies.
2
Build
Apply secure coding standards, code review, dependency controls, and protected development environments.
3
Test
Use automated scanning, functional security testing, permission testing, and targeted manual review.
4
Operate
Monitor production behavior, manage vulnerabilities, investigate events, and improve controls over time.
Different users. Consistent protection principles.
SDS is designed to protect information submitted by both buyers and suppliers while maintaining appropriate ownership, access, and sharing controls.
Controlled program and user access.
Buyer organizations should be able to manage who can administer programs, review supplier information, access reports, and configure modules.
- Role-based buyer permissions
- Administrative access controls
- Review and workflow visibility
- Audit history for material actions
- Organization-level data separation
Controlled program and user access.
Suppliers should understand what information they maintain, who can access it, and how it is used across participating buyer relationships.
- Supplier account ownership and administration
- Controlled sharing with authorized buyers
- Secure document submission
- Change history and status visibility
- Clear retention and deletion practices
Prepare, detect, respond, and recover.
Security incidents require clear ownership, escalation, communication, and post-incident improvement.
Preparation
Defined roles, contact paths, severity criteria, and response procedures.
Detection
Monitoring, alerts, user reports, and investigation of unusual activity.
Containment
Limit impact, protect affected systems, and preserve relevant evidence.
Recovery
Restore service, communicate appropriately, and implement corrective actions.
Support enterprise security due diligence.
SDS can provide appropriate security information to qualified customers, partners, and reviewers under suitable confidentiality protections.
Security questionnaires, architecture summaries, data-flow information, and supporting materials should be provided only after they have been formally reviewed and approved.
Security contact
Customer due diligence
Available upon qualification
Security documentation
Subject to review and confidentiality
Responsible disclosure
Formal policy recommended before launch
Certifications
Do not claim until independently verified
Important: Do not publish claims such as SOC 2, ISO 27001, HIPAA compliance, PCI DSS compliance, penetration-tested, 99.9% uptime, or continuous 24/7 monitoring unless those claims are accurate, current, documented, and approved.
Protect supplier relationships with a security-conscious platform.
SDS is designed to support secure buyer and supplier collaboration through controlled access, protected data handling, traceability, and disciplined platform operations.