Information Security & Data Protection

1. Risk-based security

Security controls are selected according to the nature of the engagement, the sensitivity of accessible information, technical feasibility, contractual requirements, and identified risk. No universal control set is appropriate for every small or mid-sized business. A project may therefore require additional written safeguards, data-processing terms, or client-specific procedures.

Security is an ongoing process, not a one-time product. Changes in personnel, vendors, threats, law, architecture, and business operations require reassessment. A point-in-time review does not certify future security or eliminate residual risk.

2. Access management

Access should be authorized, unique to the individual where supported, limited to the minimum privilege required, protected by multi-factor authentication, logged, reviewed, and removed when no longer needed. Administrative access is used only for approved work. Shared credentials and persistent unrestricted accounts are discouraged.

The client controls authorization to its environments and must identify permitted systems, contacts, and actions. We do not request passwords, recovery codes, or authentication tokens through the website form. Credential exchange should use an approved secure method. Temporary credentials should be rotated or revoked after the relevant task.

3. Data minimization and handling

We seek to access only the information necessary to perform the accepted scope. Clients should avoid providing unrelated personal, confidential, regulated, or high-risk data. Test or redacted data should be used where practical. Project files should be stored in approved locations with access appropriate to the engagement.

Information may be transmitted using encryption in transit where supported and stored using provider encryption and access controls appropriate to the tool. Local exports, diagnostic bundles, and temporary working files should be removed when no longer required, subject to legal retention, secure backup cycles, and the governing agreement.

4. Devices and workforce practices

People with project access are expected to use access controls, current security updates, malware protection where appropriate, device encryption where supported, screen locking, secure networks, confidentiality obligations, and reasonable physical protection. Access may be limited by role and reviewed when responsibilities change.

The client is responsible for security of its own devices, workforce, physical spaces, local networks, account recovery methods, and internal policies. Our controls cannot compensate for unmanaged client access, undisclosed accounts, unsupported equipment, or user actions outside the scope.

5. Vulnerability and configuration management

Supported systems should receive vendor updates according to risk and operational testing. Critical exposures may require expedited change. Unsupported software, end-of-life hardware, default credentials, exposed administrative interfaces, excessive permissions, and missing logs materially increase risk and should be addressed through an agreed plan.

A cybersecurity assessment uses available evidence and reasonable methods within the agreed scope. It is not necessarily a penetration test, source-code audit, forensic investigation, compliance audit, or guarantee that every vulnerability will be found. Those services require separate authorization and rules of engagement.

6. Backup and resilience

Important data should follow a documented backup strategy that addresses frequency, retention, separation, encryption, monitoring, recovery points, recovery times, and restoration testing. A backup status message alone does not prove recoverability. Critical restorations should be tested periodically and after material architectural change.

The client must determine which systems and records are business-critical, how much data loss and downtime are tolerable, and which legal retention duties apply. Unless expressly managed by us, the client is responsible for ongoing backup operation and verification.

7. Logging and monitoring

Where included and supported, systems may record authentication, administrative activity, service health, alerts, errors, and security events. Monitoring is limited by tool coverage, configuration, retention, connectivity, vendor capability, and the agreed support window. It does not guarantee real-time detection or prevention of every event.

Logs may contain account identifiers, IP addresses, device information, event timestamps, and limited content necessary for troubleshooting. Access and retention should be restricted to legitimate security, operational, contractual, and legal purposes.

8. Incident response

A suspected incident should be reported immediately to the security contact with a safe summary and reliable callback information. Do not destroy evidence, wipe systems, pay a ransom, communicate with an attacker, or make public statements without appropriate authority and professional advice. Containment actions may interrupt operations and require executive approval.

We will investigate incidents affecting systems under our control and cooperate within the contracted scope. Response may include triage, containment recommendations, credential rotation, log preservation, vendor escalation, recovery support, and documentation. Legal notification, law-enforcement contact, insurance reporting, forensic certification, and public communication remain client responsibilities unless expressly assigned.

9. Third-party and cloud risk

Cloud, software, hosting, payment, security, and collaboration providers operate independent systems. We may assess available security information and configure client-controlled settings, but we do not guarantee a provider’s security, uptime, data location, future features, or incident response. The client remains bound by provider terms and must maintain ownership and recovery access.

10. Data protection roles

For ordinary business contacts, each party generally handles information for its own legitimate business purposes. If we process personal information solely on a client’s behalf, the client determines lawful purpose, notices, rights handling, retention, and instructions, while we follow documented instructions and agreed safeguards. A separate data-processing addendum may be required before regulated or sensitive processing begins.

11. Security reports and responsible disclosure

A person who believes the website or a system under our control has a vulnerability should report it privately to the security address. Reports should identify the affected asset, observed behavior, reproduction steps, and contact details without accessing unrelated data, causing disruption, using social engineering, demanding payment, or publicly disclosing an unverified issue. Authorization to test is not granted by this notice.

12. Exceptions and review

A control exception should identify the business reason, affected assets, owner, duration, risk, and compensating safeguards. Exceptions may be rejected when risk is unacceptable. Security practices and this notice may be revised as services, threats, providers, and legal duties evolve.