Security & confidentiality
Client information is treated as confidential
QA work can involve test environments, screenshots, logs, API responses, product plans, unreleased features and internal workflows. Access and evidence should be handled with clear rules from the start.
Practical safeguards
Clear rules before access is shared
Before testing starts, the client and QA provider should agree what can be accessed, what data can be used, how findings are reported and what should be deleted or returned after the work.
Confidentiality
Non-public product information, screenshots, logs, API responses, findings and internal workflows are treated as confidential.
NDA coverage
Work can be covered by your NDA or a mutual NDA before product access, documentation or sensitive project details are shared.
GDPR and data processing
If testing involves personal data, processing scope, instructions, retention and deletion expectations should be agreed before work starts.
Least-privilege access
Testing should use named accounts with only the permissions needed for the agreed scope. Production access should be avoided unless clearly agreed.
Controlled evidence
Bug reports and QA summaries include useful evidence, but should avoid unnecessary personal data, secrets or unrelated sensitive information.
Approved tools and channels
Reports, screenshots, logs and credentials should be shared through client-approved tools or secure channels agreed before the work begins.
Access and credentials
Clients should provide named test accounts with only the access required for the agreed testing scope.
Passwords, API keys, private keys and other secrets should not be sent through unsafe chat channels. A password manager, temporary credentials or client-approved access method should be used where possible.
Production access should be avoided unless the scope clearly requires it and both sides agree how it will be handled.
Test data and personal data
QA work should use test data whenever possible. Real customer data should only be used when it is necessary, lawful and explicitly agreed.
If the work requires handling personal data on behalf of the client, a Data Processing Agreement or equivalent data processing terms may be needed.
The client remains responsible for deciding what data may be used for testing and what restrictions apply to that data.
Screenshots, logs and reports
Testing evidence should be focused on what developers need to understand and fix the issue.
Screenshots, videos, logs and API responses should avoid unnecessary personal information, credentials, private tokens or unrelated customer data.
If sensitive information appears in evidence, it should be masked, removed or handled through an agreed secure channel.
Use of AI tools
Client confidential information, credentials, customer data, private source details or sensitive logs should not be entered into public AI tools unless the client explicitly approves it.
AI tools may be useful for general writing, formatting or non-sensitive QA thinking, but client confidentiality comes first.
Third-party tools and sub-processors
QA work may involve normal business tools such as email, issue trackers, cloud storage, password managers, test tools or client-provided systems.
Where a client requires specific tool restrictions, approved channels or sub-processor limits, those expectations should be agreed before access is shared.
Project closure
At the end of the work, client access should be removed or disabled unless ongoing support is agreed.
Temporary local files, exported logs and working notes can be deleted after delivery where appropriate.
Final deliverables should be handed over through agreed channels so the client keeps the useful QA output without leaving unnecessary access open.
If something goes wrong
If confidential information, credentials or sensitive data appear to be exposed, the client should be informed quickly through the agreed contact channel.
The next step should be practical: remove the exposed material, rotate credentials if needed and agree whether any further action is required.
Certifications and scope
Laidoner Solutions is not currently presented as an ISO 27001 or SOC 2 certified provider.
The current approach is practical: confidentiality, least-privilege access, careful evidence handling, GDPR-aware working practices, approved channels and clear agreements before testing starts.