Data processing agreement and sub-processors
A data processing agreement template and a list of providers that may participate in service delivery are available for review.
Zero-trust architecture
Security Architecture
We describe security through concrete mechanisms, documents, and responsibilities: from sign-in and data access to the audit trail.
Security package
Buyer due-diligence documents available on request
During an implementation conversation, we share or discuss the materials needed for vendor risk assessment. We do not publish operational parameters without confirming the service scope.
Hosting, backups, and recovery
Hosting model, backup approach, service recovery time, and acceptable data-loss scope after an incident are confirmed for the specific implementation.
Incident procedure
We describe the reporting channel, incident qualification, roles on both sides, and the expected communication flow.
Management system status
A management system based on ISO 27001 is implemented. Certification is not currently planned, and selected system documents can be made available to customers on request.
Identity & Access
Zero-trust authentication and authorization
External sign-in provider
Users sign in through an external identity provider. The application does not store local passwords, and roles follow the responsibilities agreed for the organization.
Role-based access with time-limited delegations
Access can be limited to a specific work area and granted only for a defined period. After the delegation expires, permissions return to the previous scope.
Policy engine
Before an important action is performed, the system checks who is acting, which object is affected, and why. A missing access basis should block the action.
Four-eyes approval workflow
Higher-risk actions can require approval from a second person. The decision, rationale, and approval time remain visible in the process history.
Data Protection
Encryption, classification, and data sovereignty
Data classification
Data is marked by sensitivity, for example as public, internal, confidential, or personal data. Sensitive fields can be hidden in the interface and system responses.
Customer-managed encryption keys
The encryption-key model is agreed during implementation. Where stronger control is needed, the customer can manage its own keys or agree a dedicated key-handling model.
Least-privilege database access
Technical database access is limited to the scope needed by each part of the system. Pre-release tests check that access has not become too broad.
Export approval gate
Exports of confidential or personal data can require an additional approval. If required approvals are missing, the export is blocked and recorded in the history.
Audit Trail
Audit trail with cryptographic verification
Event log with integrity verification
The event log records important actions in an order that can later be checked for integrity. A break in that record should trigger a security alert.
Evidence package with cryptographic verification
An evidence package includes the list of items, data scope, and operation history. This helps an auditor see what was shown and which period it covers.
Organization data isolation
Organization data is separated from other customers' data and restricted through access policies. The isolation scope is confirmed in the implementation model.
Access log for evidence packages and exports
Every evidence package download, export, or report leaves a trace: who, when, which data scope, and for what purpose.
Infrastructure and releases
Security checks before changes are released
Security gate
Before release, dependencies, known vulnerabilities, and basic security risks are checked. High-risk changes should not be released without a decision from the responsible person.
Library controls
The list of libraries and versions is kept repeatable. Known unsafe versions should be blocked or moved into a fast update path.
Hardened error tracking
Error logs should remove personal data, access tokens, and other sensitive information. The goal is to diagnose problems without exposing customer data.
Sign-in process monitoring
The sign-in process is monitored because it affects evidence access and user accountability. Sign-in issues are treated as an operational risk.
Security update path
Important vulnerabilities have an owner, remediation status, and priority decision. This keeps security updates from disappearing into the regular work queue.
Security — FAQ
By default, we assume data hosting in the European Union. Exact location, retention, and infrastructure requirements are confirmed in the implementation agreement.
Yes, if agreed in the implementation scope. In that case we describe who manages encryption keys, how key rotation works, and who is responsible for access to them.
Organization data isolation is part of pre-release testing. Backup, restore, and disaster-recovery scope are confirmed in the implementation arrangements.
The event log records important operations in a way that supports checking the continuity of the history. An integrity issue should trigger a security alert and review.
Pulsar GRC
Ready to organize risk and compliance?
Let us review the process that still requires too much manual work: requirements, controls, evidence, CAPA, audits, and reporting.
Contact: kontakt@pulsar-grc.pl
