How we approach security and compliance
We design our practices to align with recognised security and compliance frameworks. This page documents our current approach, our near-term compliance roadmap, and how we handle client data, so you can make an informed decision.
Note: Mobile Application Testers is a newer business. We do not currently hold SOC 2, HIPAA, or PCI DSS certifications. The information below describes our current practices and the frameworks we are aligned with and working toward. Clients in regulated industries should review this page and discuss specific requirements directly with us before engagement.
Compliance approach
Framework alignment and roadmap
We design our practices to align with the compliance frameworks most relevant to regulated mobile app development, and we are transparent about where we currently stand on each.
SOC 2 alignment
Framework we design towardOur processes are designed to align with SOC 2 Trust Services Criteria covering Security, Availability, and Confidentiality. We are building the operational controls, access management, change management, incident response, and vendor oversight, that a SOC 2 Type II audit examines. We do not currently hold a SOC 2 certification. Clients with formal vendor assessment requirements should discuss their specific needs directly.
Current practices
- Access management based on least-privilege principles
- Logical separation of client test environments
- Documented incident response procedures
- Change management for all production systems
- Vendor review process for sub-processors
- SOC 2 audit is a near-term operational milestone
HIPAA-aware practices
Aligned, not certifiedFor clients whose mobile applications handle Protected Health Information (PHI), we apply HIPAA-aware practices: synthetic test data, environment isolation, and enhanced access controls. We are prepared to discuss and execute Business Associate Agreements with healthcare clients as our practice scales. We do not claim current HIPAA certification, we recommend clients review our practices directly for their compliance requirements.
Current practices
- PHI handling via synthetic and anonymised test data only
- Isolated test environments for health app engagements
- Enhanced access controls for sensitive data scenarios
- Prepared to execute BAAs as engagement scope warrants
- PHI never processed in non-isolated environments
- Compliance posture review available on request
Payment app security
PCI-aware designFor mobile applications that handle payment flows, we apply PCI-aware testing practices: synthetic card data, isolated test environments, and test coverage of tokenisation, encryption, and session management. We do not claim PCI DSS Level 1 certification. Clients undergoing formal PCI assessments should work with their QSA to confirm testing requirements, we are happy to provide documentation of our practices.
Current practices
- Synthetic card data used in all payment flow testing
- No real cardholder data in test environments
- Test coverage of tokenisation and encryption handling
- Session management and 3DS/SCA flow testing
- Network-isolated test environments for payment apps
- Documentation of our testing practices available on request
Data privacy practices
GDPR / CCPA awareWe do not use real user production data in test environments without explicit client agreement. For clients operating under GDPR or CCPA, we can discuss and execute Data Processing Addenda that reflect our actual data handling practices. Our Privacy Policy governs personal data collected through this website. For clients in the EU or UK, we are prepared to execute SCCs for any data transfer requirements.
Current practices
- No real production PII in test environments by default
- Data Processing Addendum available for EU/UK clients
- Privacy Policy covers website data collection
- Standard Contractual Clauses available for cross-border transfers
- Test suites for consent, erasure, and data minimisation flows
- Client data handling practices documented in engagement agreements
How we handle client data
Our default practices, applied to every engagement, for test environment isolation and data protection.
Test environment isolation
Each client's test environment is logically separate. Test artefacts, screen recordings, crash logs, defect reports, are scoped to the client engagement and not shared across clients.
Synthetic test data
Our default practice is to use synthetic test data (generated transactions, user profiles, payment details) that is structurally realistic but contains no real user information. We do not use production data snapshots in test environments unless explicitly agreed in writing.
Device practices
Devices used for testing are reset between engagements. Our test infrastructure is designed to prevent data residue from one client's test sessions appearing in another's.
Personnel access
Access to client test environments is limited to the named team members on the engagement. We maintain an access log and review access on an ongoing basis.
Encryption in transit
All test artefacts delivered to clients are transmitted via encrypted channels (TLS 1.2+). We do not transmit test results via unencrypted channels.
Engagement agreements
Our engagement agreements address data handling, confidentiality, and security responsibilities. Clients with specific security requirements should raise these during the engagement scoping process.
This website’s security headers
We apply security best practices to our own website, the same type of controls we help clients verify in their mobile apps.
Report a security issueHTTPS enforced
HSTS (max-age=63072000; includeSubDomains; preload), all HTTP redirected to HTTPS.
Content Security Policy
Strict CSP headers restrict script, style, and frame sources to explicitly whitelisted domains.
X-Frame-Options: DENY
Prevents the site from being embedded in iframes, clickjacking protection.
X-Content-Type-Options
nosniff header prevents MIME-type sniffing attacks.
Referrer Policy
strict-origin-when-cross-origin limits referrer data on cross-domain navigation.
Permissions Policy
Camera, microphone, geolocation, payment, and USB APIs disabled via header.
Dependency review
Production dependencies are reviewed and updated regularly. Vulnerability scanning is applied to the build pipeline.
Responsible disclosure
We welcome security reports. Contact us via the form below, we commit to acknowledgement within 5 business days.
Common security and compliance questions
Do you have a SOC 2 certification?
Not currently. We are building toward SOC 2 as an operational milestone as our practice scales. Clients with formal vendor assessment requirements should contact us to discuss our current controls documentation.
Can you sign a Business Associate Agreement (BAA) for HIPAA-regulated engagements?
We are prepared to discuss BAA terms with healthcare clients. Our practices for health app engagements already apply HIPAA-aware data handling principles. Contact us to discuss the specific requirements of your engagement.
How do you handle payment card data in testing?
We use synthetic card data exclusively. Real cardholder data is never used in test environments. Our payment flow testing covers tokenisation, 3DS/SCA, and wallet integrations using test credentials provided by payment processors.
Can you execute a Data Processing Addendum for GDPR purposes?
Yes. For clients in the EEA or UK who require a DPA before sharing any data, we will provide our standard DPA for your legal review, or work from your template. Contact us to initiate this process.
What happens to our test artefacts at the end of an engagement?
Test artefacts (screen recordings, defect reports, test case documentation) are delivered to the client and deleted from our systems within 30 days of engagement completion, unless a longer retention period is agreed in the engagement contract.
How do I report a security vulnerability in your website?
Use our contact form and describe the vulnerability. We commit to acknowledging responsible disclosure reports within 5 business days. We will not pursue legal action against good-faith security researchers who comply with responsible disclosure norms.
Discuss your security and compliance requirements
We are happy to provide documentation of our current practices, discuss engagement-specific compliance requirements, or review our DPA template with your legal team.