Proportionate safeguards, clearly owned.

1. Purpose and scope

MNessa Limited aims to protect the confidentiality, integrity and availability of information used in its website, communications and client work. Controls are selected according to the service, information, contractual commitments, threat and practical risk.

This public statement is not a detailed security architecture, penetration-test report, warranty or service- level agreement. Project-specific security requirements should be recorded in the relevant contract, statement of work, hosting plan or data-processing agreement.

2. Risk and governance

Security responsibilities should be assigned rather than assumed. MNessa's approach includes identifying the information and systems involved, considering plausible threats, applying proportionate controls, recording material decisions and reviewing risk when the service or supplier changes.

Higher-risk work may require additional measures such as a security schedule, data-flow review, access matrix, backup plan, recovery objective, vulnerability assessment or client approval before production deployment.

3. Identity and access

MNessa's baseline approach is to:

• use individual accounts rather than shared credentials where the platform supports them;
• enable multi-factor authentication for important business, source-control, hosting and administrative accounts where available;
• use strong, unique credentials managed through an appropriate password-management process;
• grant the minimum access reasonably needed for the role or task;
• review and remove access when a project, role or supplier relationship ends; and
• avoid placing secrets or production credentials in public repositories, source files or ordinary chat messages.

4. Devices and communications

Devices used for MNessa work should use supported software, access protection, timely security updates and appropriate encryption features. Remote access and public networks should be used with care, and highly sensitive material should be shared through a channel appropriate to its risk rather than an ordinary website form.

Website traffic should use HTTPS. Email is useful but does not guarantee confidentiality or delivery; a more controlled transfer method may be agreed for credentials, personal data, backups or restricted client files.

5. Secure development and change

Depending on the service and scope, MNessa may apply practices such as:

• version control and reviewable change history;
• separation of configuration and secrets from source code;
• dependency, update and vulnerability review;
• input validation, output handling, rate limits and anti-abuse controls;
• testing in an appropriate non-production environment before release;
• least-privilege service accounts and scoped API credentials;
• logging sufficient for diagnosis without deliberately collecting unnecessary sensitive data; and
• rollback, backup or recovery planning proportionate to the change.

No development method removes all vulnerabilities. Security-sensitive findings are prioritised according to likelihood, impact, exposure and available mitigations.

6. Hosting, suppliers and international processing

MNessa commonly relies on reputable managed providers for hosting, deployment, source control, email, productivity, payment or monitoring. Supplier suitability is considered according to the information and service involved, including available security controls, contractual terms, sub-processors, resilience and data-location or transfer arrangements.

A well-known provider is not automatically suitable for every client. Regulated, sensitive or location- restricted work may require a separately agreed architecture and supplier list.

7. Backups, recovery and continuity

Backup responsibilities depend on the service. Website Care Plans, hosting management and custom systems may have different backup scope, frequency, retention and recovery arrangements. These should be confirmed in the applicable client terms rather than inferred from this statement.

Where MNessa is responsible for backups, it aims to use proportionate automated or managed processes and to consider restoration, not merely creation of a backup. Clients remain responsible for retaining their own source information and for responsibilities specifically allocated to them.

8. Security incidents

MNessa aims to identify, contain, assess, document and recover from security incidents. Relevant clients, providers, insurers, authorities or affected people will be informed where a contract or law requires it. Personal-data breaches are assessed under applicable data-protection rules, including regulatory notification where the legal threshold is met.

Incident lessons should be used to improve controls, documentation and supplier decisions. Public disclosure may be limited while an issue is investigated or where detail could increase risk.

9. Data minimisation, retention and disposal

MNessa aims to collect only information reasonably needed for the purpose, limit unnecessary copies and retain information according to business, legal and contractual requirements. When information or access is no longer needed, it should be deleted, anonymised, revoked or securely disposed of using a method appropriate to the system and risk.

10. People and confidentiality

People with access to MNessa or client information should understand their responsibilities, use approved accounts and tools, report suspected incidents and respect contractual or professional confidentiality. Contractors should receive access and information proportionate to their task and be subject to appropriate terms where necessary.

11. Shared responsibility

Security is shared. Clients may be responsible for:

• providing accurate requirements and identifying regulated or especially sensitive information;
• controlling their users, devices, passwords and internal access;
• keeping independent copies of important source content where agreed;
• using supported software and following security instructions;
• reviewing and approving access, suppliers or releases allocated to them; and
• promptly reporting suspicious activity, compromised credentials or material changes.

The applicable contract should clarify responsibility rather than relying on assumptions.

12. Reporting a vulnerability or incident

Send a private report to contact@mnessa.co.uk with the subject Security report. Include the affected page or service, steps to reproduce, observed impact and safe supporting evidence. Do not access unnecessary data, disrupt service, demand payment, use social engineering or publish an unresolved issue without giving MNessa a reasonable opportunity to investigate.

13. Assurance and limitations

MNessa does not currently claim certification to ISO 27001, Cyber Essentials or another formal security standard unless expressly confirmed in writing. This statement describes MNessa’s operating baseline and is reviewed against actual practice periodically.

Security cannot be guaranteed absolutely. This statement does not expand contractual warranties, support obligations or liability beyond those agreed for a specific service.