Security by design.
An engineering-grade overview of how Infosec Tools protects customer data: encryption, isolation, identity, application security, audit logging, and alignment with ISO 27001:2022, GDPR and NIS2.
Our approach
Infosec Tools is built and operated by information security practitioners. Security is not a layer added on top: it is part of how the product is designed, written, deployed, and run every day.
Security-by-design
- Threats considered before features are written, not after
- Least-privilege defaults for every new capability
- Failure modes designed to fail closed, not open
- Security reviews are part of every change
ISMS-driven operations
- Internal practices follow our own ISO 27001:2022 framework
- The platform we build is the platform we use to govern ourselves
- Incident, change, risk and access processes are documented
- Practices reviewed and updated as the threat landscape evolves
Data protection & encryption
Customer data is protected in transit and in storage, and is never shared outside the platform.
Encryption in transit
- TLS 1.2+ enforced on every connection
- HTTP Strict Transport Security enforced platform-wide
- HTTP requests are unconditionally redirected to HTTPS
- Modern cipher suites delivered at the edge
Encryption at rest
- Sensitive database fields encrypted at the application layer
- Backups encrypted at rest by the storage provider
- Secrets stored outside the application code, with restricted file permissions
- Credentials are never logged or returned in API responses
Data minimisation
- Only the data needed for the ISMS is collected and processed
- No advertising trackers, no third-party analytics
- No data shared with brokers or advertisers, ever
- Contact details of other people hidden from the profiles that do not need them
- Customer data is never used to train AI/ML systems
Tenant isolation
Every customer runs in a fully separated environment. Data, files, credentials, and email identity are independent. There is no shared application instance and no shared database.
Separation at every layer
- Dedicated database per customer, with its own credentials
- Dedicated filesystem per customer, with its own system account and no shared writeable paths
- Dedicated subdomain per customer with its own TLS certificate
- Dedicated configuration per customer: name, address, branding and settings
No data crossover
- Application credentials are scoped to the customer's database only
- One customer cannot read or write another customer's data, by architecture and not by configuration
- Audit trail is kept per tenant; cross-tenant queries are not exposed to the application
- Backups are taken and restored per tenant, never as a single bulk export
Identity & access
Every account is protected by strong authentication. Permissions are enforced in the server-side controllers, not only in the user interface.
Authentication
- Two-factor authentication with authenticator apps (Google Authenticator, Authy, 1Password and others) or one-time codes
- Password rules enforced on every account
- Forced reset for first sign-in and for administrator-initiated rotation
- Failed sign-in throttling per account and per address
- Open sessions end at once when an account is switched off
Session security
- Session cookies are scoped, encrypted in transit, and protected against cross-site reuse
- Session integrity verified on every request
- Idle timeout enforced; sessions destroyed on logout
- Session identifier rotated on privilege changes
- Automatic sign-out after inactivity, with a warning before it happens
Authorisation
- Role-based access control with multiple profiles, including dedicated profiles for Auditors and Suppliers
- Page-level permissions (View / Create / Edit / Delete) enforced per profile
- Workflow roles orthogonal to profiles, for approvals and ownership
- Read-only profiles for auditors, who can consult evidence without changing anything
- Permissions enforced server-side on every request, not only in the UI
Privileged operations
- "Test as user" impersonation explicitly logs both the original and the simulated user
- Privileged administrative actions are subject to additional safeguards and re-checked server-side
- Destructive actions require CSRF tokens and confirmation
- Account deactivation preserves the audit trail intact
Application security
The application is hardened against the OWASP Top 10 and reviewed continuously by the same engineers who build it.
Secure development lifecycle
- Separated development, staging and production environments: changes flow through staging before reaching production
- Every change version-controlled, reviewed, and audited before deployment
- Production deployments are deliberate and traceable
- No customer data used in development or staging
Injection & input handling
- Parameterised queries everywhere; SQL strings are never concatenated with user input
- Server-side input validation on every form
- Uploaded documents and evidence validated by type and size, stored outside the web root and served only to people allowed to see them
- Strict allow-lists for enums and identifiers
Cross-site protections
- CSRF tokens on every state-changing form
- Output encoding on every dynamic value rendered to HTML
- Content Security Policy enforced platform-wide
- Self-hosted frontend dependencies: no third-party script supply chain
HTTP security headers
- Strict-Transport-Security, enforced platform-wide
- X-Frame-Options, enforced
- X-Content-Type-Options, enforced
- Referrer-Policy, enforced
- Permissions-Policy: sensitive browser capabilities denied by default
- Aligned with current OWASP and Mozilla Observatory recommendations
Infrastructure & network
The platform is hosted on a hardened, dedicated Linux server, behind a content delivery network.
Edge protection
- A content delivery network in front of the platform absorbs traffic peaks and distributed attacks
- A web application firewall and malware scanning run on the server
- Automated abuse is detected and challenged
- Traffic is encrypted end to end, from the browser to the server
Origin server
- Hardened Linux server, kept on a current patch level
- Managed under documented change control
- Operating system and application packages updated on a regular cadence
- Privileged access strictly limited; unused services disabled
Email security
- Outbound mail via a managed email service
- SPF, DKIM and DMARC published for the sending domain
- Bounce and complaint handling reviewed regularly
Media & assets
- Training videos protected by signed, expiring URLs: no permanent public links
- Application assets served from the same domain
Audit & accountability
Every action a user takes is recorded. Records are designed to satisfy ISO 27001:2022 expectations and to be exportable for internal and external audit.
What is logged
- Every action, recorded with actor, timestamp, IP, and context
- Logins, login attempts, and 2FA events
- Permission changes and privileged operations
- Data creation, modification, deletion, and export
- Document approvals, acknowledgments, and review cycles
How it is preserved
- Audit trail entries are never edited, and are kept for the retention period each organisation sets
- Impersonation events keep both the operator and the simulated user identifiable
- History is preserved when records are deactivated, not destroyed
- Audit data is exportable in standard formats for evidence collection
Backups & resilience
We back up customer data daily, store it independently of production, and test that we can restore it.
Backup strategy
- Daily backups of databases and uploaded files
- Stored encrypted in a separate location, geographically isolated from production
- 90-day retention enforced via lifecycle policy
- Per-tenant scope: customers can be restored independently
Monitoring & recovery
- Uptime monitored externally with alerting on failure, with live status published at status.infosectools.info
- Error rates and slow paths reviewed regularly
- Restore procedures documented and exercised
- Service status communicated to affected customers when relevant
Privacy & regulatory alignment
Privacy is a first-class concern, not a checklist. Customer data belongs to the customer; we are processors, not owners.
GDPR
- Data Processing Agreement available on request
- Data subject rights honoured: access, export, rectification, erasure, portability
- Privacy-by-design and privacy-by-default
- Sub-processors are documented and reviewed
- Notification of affected customers in line with GDPR Article 33 timelines
NIS2
- Practices aligned with the EU Directive 2022/2555 on network and information security
- Risk management, incident handling, and supplier security treated as ongoing obligations
- Incident notification flow tested and documented
- Designed to support customers operating in NIS2-regulated sectors
- The platform prepares incident notifications in the structure the authorities ask for
ISO 27001:2022
- The platform is built around the controls and clauses of ISO 27001:2022
- Internal operations follow the same ISMS we deliver to customers
- Annex A controls drive the product roadmap
- Evidence and audit artefacts are first-class outputs, not afterthoughts
Sub-processors
- Hosting infrastructure
- Content delivery and protection at the edge
- Email delivery
- Encrypted backup storage
- Video delivery for training content
- Customers receive prior notice of material changes to the sub-processor list
Standards & frameworks
We work to recognised standards. We are clear about what we are aligned with versus what we are certified to.
ISO 27001:2022
The platform is engineered around the clauses and Annex A controls. Internal practices follow the same ISMS framework.
GDPR
Aligned with EU Regulation 2016/679. A Data Processing Agreement is available on request.
NIS2
Practices aligned with EU Directive 2022/2555: risk management, incident handling, and supplier security as ongoing obligations.
Reporting a vulnerability
If you believe you have found a security issue in Infosec Tools, please tell us. We take every report seriously and will follow up.
Found something? Let us know.
Use the contact form to report any potential security issue. Please include a brief description, steps to reproduce, and any evidence you can share. Mark the message as [SECURITY] in the subject line so it is routed appropriately.