Security posture in plain language
Procuraz is a multi-workspace business system, so authorization and organization boundaries are as important as infrastructure controls. The security programme is designed around least privilege, tenant-aware access, secure development, logging, backups and responsible incident handling.
This page intentionally avoids unverified certification badges or absolute security guarantees.
Procuraz’s security programme is designed to protect a multi-organization procurement SaaS environment used by platform administrators, customer companies, employees, vendors and seller partners. Controls are selected according to data sensitivity, user role, organization boundary and operational risk.
This page is a public security overview, not a guarantee that incidents are impossible and not a substitute for a signed security schedule, service-level agreement or customer risk assessment.
Security depends on Procuraz, hosting and service providers, customer administrators and individual users. Procuraz is responsible for operating and protecting the platform components under its control. Customers are responsible for lawful data, appropriate configuration, user lifecycle, device security and minimum-necessary access.
Vendors and seller partners must protect their own users and credentials and must not assume that access to one portal authorizes access to another organization or workspace.
The product model separates platform-owner administration, customer company workspaces, vendor organizations and seller-partner operations. Authorization checks should use the authenticated organization and role rather than relying only on interface visibility.
- Company data is scoped to the relevant tenant and permitted relationships.
- Vendor access is limited to supplier-owned information and company interactions made available to that vendor.
- Seller-partner activity is separate from supplier and customer company workspaces.
- Platform staff access should follow least privilege and operational need.
Tenant isolation and authorization must be included in security testing whenever APIs, reports, exports or administrative features change.
- Individual accounts are required; shared credentials are prohibited.
- Passwords should be stored using strong one-way hashing rather than reversible encryption.
- Sessions and tokens should have appropriate expiry, validation and revocation controls.
- Administrative and high-impact actions should require stronger authorization and may require additional verification.
- User, role and department changes should be logged and reviewed.
- Departed or inactive users should be removed promptly by the relevant organization administrator.
Users must never send passwords, OTPs, access tokens or private keys through support email or the website contact form.
Production websites and application interfaces should be served over HTTPS using current TLS configurations. Security headers, secure cookie attributes, appropriate cross-origin rules and restricted administrative endpoints form part of the web security baseline.
Users should access only official procuraz.com domains and must not bypass browser certificate warnings. Network exposure, database access and management interfaces should be limited to the minimum required.
The development lifecycle should include input validation, output encoding, parameterized database access, authorization at the server, dependency review, secret scanning, secure configuration and testing for common web and API risks.
Security-sensitive changes—such as authentication, tenant filtering, file upload, payment, vendor approval, export and administrative controls—require focused review before deployment. Production error messages should avoid disclosing secrets, internal paths or sensitive records.
Data protection measures should reflect classification and business need. The baseline includes secure transport, restricted database and object-storage access, separation of credentials from source code, protected backups and controlled administrative access.
Private keys, database passwords, SMTP credentials, payment secrets and API tokens must be stored through approved environment or secret-management mechanisms and rotated when exposure is suspected.
Uploaded vendor documents and procurement attachments should be checked for permitted file type, size, authorization and safe delivery. Public URLs must not expose private tenant files.
Security and operational logging should capture authentication events, material administrative changes, permission changes, vendor review decisions, important transaction actions, errors and suspicious activity while avoiding unnecessary logging of passwords or secret values.
Logs are used for troubleshooting, audit support, abuse detection and incident investigation and are retained according to operational and legal requirements.
Procuraz should maintain awareness of vulnerabilities affecting its frameworks, dependencies, hosting and infrastructure, prioritize findings according to exploitability and impact, and apply remediation or compensating controls within a risk-appropriate period.
Automated scanning supports but does not replace code review, authorization testing and validation of business logic. Findings involving tenant isolation, authentication, payment, file access or privilege escalation receive heightened attention.
Production data should be backed up according to the hosting architecture and recovery objectives. Backup access must be restricted and restoration procedures should be tested periodically.
Backups reduce the risk of accidental loss but are not an archival substitute for customers. Customers should export records required by their own legal, tax, audit or continuity obligations when export functionality is available.
Procuraz’s incident process should include detection, triage, containment, eradication, recovery, evidence preservation, root-cause analysis and corrective actions. Access may be reset or restricted when necessary to protect the service.
Affected customers, individuals and authorities will be notified when required by applicable law or contract, based on the nature, scope, risk and confirmed facts of the incident. Security investigations may require cooperation from customer administrators and service providers.
Procuraz may use hosting, database, storage, email, payment, monitoring and support providers. Providers should be selected based on service suitability, security capability, contractual protection and operational reliability.
Third-party incidents and outages may affect the Services. Procuraz will use reasonable efforts to manage provider risk and maintain alternatives or recovery measures appropriate to the platform stage and customer commitment.
Access by Procuraz personnel should be limited to legitimate support, engineering, security, billing or legal need and should use individual accounts. Administrative access should be reviewed and removed when no longer required.
Personnel with relevant access should receive confidentiality and security guidance. Sensitive production actions should be traceable and, where practical, separated from routine development access.
- Assign the minimum role required and review permissions regularly.
- Remove users promptly when employment or responsibility changes.
- Use strong unique passwords and protect the associated email account and device.
- Verify vendor invitations and banking changes through appropriate business controls.
- Do not upload unlawful data or secrets that are not required by the workflow.
- Use supported browsers and install operating-system and browser updates.
- Report suspicious activity, unexpected access or security warnings promptly.
- Maintain independent records or exports required for legal and continuity obligations.
Security researchers should email tech@procuraz.com before public disclosure. Include the affected domain or endpoint, vulnerability type, impact, reproducible steps and non-destructive evidence.
Permitted good-faith research: testing your own accounts and data, avoiding privacy impact, stopping when sensitive data is encountered, and allowing reasonable time for investigation.
Prohibited activity: denial-of-service testing, spam, social engineering, physical intrusion, destructive exploitation, accessing unrelated customer data, persistence, extortion, public disclosure before remediation, or testing third-party services without permission.
Procuraz does not intend to initiate legal action solely for good-faith research that follows this policy, avoids harm and complies with law. This statement does not authorize activity against third-party systems or waive rights relating to malicious or reckless conduct.
Procuraz does not claim ISO 27001, SOC 2, PCI DSS or other certification merely because a hosting or payment provider has one. A certification applies to Procuraz only when formally achieved, current and explicitly stated in a verifiable document.
Customers evaluating security may request available architecture, control or contractual information. Information that could increase security risk may be shared only under appropriate confidentiality restrictions.
Report security vulnerabilities, suspicious technical behaviour or potential exposure to tech@procuraz.com. General account-access issues may be sent to support@procuraz.com.