In plain terms
This describes how We Solve Problems protects information inside our own business — our systems, our staff, and the client data we hold. It is not a description of your environment, and it is not a certification of anything. Your own obligations are in section 7 and section 26 of the Services Agreement.
1. What this policy is, and what it is not
This policy describes the information security programme We Solve Problems, LLC operates for its own business: the administrative, physical, and technical safeguards we apply to the information we hold, including client information.
It applies to every person who works for us — employees, contractors, and anyone with access to our systems.
It is not an assessment of Client’s environment, and nothing in it is a certification, an audit result, or a statement that Client complies with any law or framework. Client’s own obligations sit in section 7 and section 26 of the Services Agreement, and where we deliver compliance services, Part Three governs.
2. Who is responsible
A named Security Coordinator owns this programme and reports to the Chief Executive Officer. The Coordinator is responsible for:
- maintaining this policy and the safeguards under it;
- running the risk assessment described in section 3;
- making sure staff are trained on the parts that apply to them;
- reviewing the programme at least annually, and after any material change to our systems, our services, or the law; and
- acting as the standing member of the incident team described in the Incident Response Plan.
Security is not delegated to a department, because we do not have departments. It is one accountable person with the authority to stop work that creates unacceptable risk.
3. Risk assessment
We identify and assess the internal and external risks that could lead to unauthorised access, disclosure, misuse, alteration, or destruction of the information we hold.
The assessment covers, at minimum:
- People — how access is granted, reviewed, and removed, and how staff are trained
- Systems — network and application design, and how information is processed, stored, transmitted, and disposed of, in both electronic and paper form
- Threats — how we detect, prevent, and respond to attacks, intrusions, and failures, including continuity of the business during one
- Vendors — the third parties that hold or can reach information on our behalf, listed in the Schedule of Third-Party Services
- Artificial intelligence — where AI tools touch information, under section 7 below
For each risk we record the safeguard that addresses it and whether that safeguard is sufficient. Where it is not, the gap is tracked until it is closed or accepted in writing.
4. Administrative safeguards
Access is granted by role and reviewed. People get the access their work requires and no more. Access is granted on joining, changed when a role changes, and removed when someone leaves.
Credentials are managed, not remembered. Shared and privileged credentials live in a managed password system. Credentials are not stored in documents, spreadsheets, tickets, chat, or email, and are not reused across clients.
Multi-factor authentication is required on every system that supports it, for every person, including administrators.
Staff are trained on this policy, on recognising phishing and social engineering, and on the wire-transfer control in section 6, when they join and periodically afterwards.
Activity is logged and reviewed. Administrative actions, authentication events, and security alerts are recorded, and the records are reviewed on a regular cadence and whenever something looks wrong.
Failure to follow this policy is a disciplinary matter, up to and including termination and removal of access.
5. Physical and device safeguards
Devices are managed. Every device used for our work is enrolled in management, is encrypted at rest, locks automatically, and runs endpoint detection with current definitions.
Unsupported software is replaced. Operating systems and applications are kept on supported, patched versions. Where something cannot be upgraded immediately, it is isolated until it can be.
Media is disposed of, not discarded. Storage media is wiped or destroyed before disposal or reuse, and paper containing client or personal information is shredded.
Physical access is controlled. Our premises and any equipment holding information are secured against unauthorised access, and visitors are supervised.
6. Technical safeguards
Unique identity. Every person has their own account. Shared logins are not used where a system supports individual accounts.
Encryption. Information is encrypted in transit, and at rest wherever the system involved supports it.
Least privilege. Administrative rights are restricted to the people and systems that need them, and are separated from day-to-day accounts.
Network controls. Perimeter filtering, email filtering for malicious attachments and links, and restriction or disabling of remote-desktop endpoints exposed to the internet.
Backups. Backups are taken on a defined schedule, held independently of the primary environment, and tested for restorability rather than assumed.
Funds transfers. No funds are transferred on the strength of an emailed instruction. New or changed account details are verified by voice on a previously known number, following the Confirmation of Wire Instructions.
7. Artificial intelligence
AI tools are covered by this programme rather than exempt from it.
Information is not placed into an AI tool that the tool’s terms do not protect. Plan type governs how a vendor handles input, and consumer plans generally lack the protections that client or regulated information requires.
Regulated data goes into no AI tool unless the engagement identifies it, the plan supports the required protections, and the vendor has signed the agreement the law requires. This mirrors section C.6 of the Data Processing Agreement.
AI systems that can act, not just write, are configured to least privilege. No AI system holds an unattended credential that can write to or delete a production system, a backup, or a payment system, absent an explicit authorisation naming the compensating controls. This mirrors section 9.2 of the Service Attachment for Artificial Intelligence Services.
AI features that vendors enable inside existing products are treated as changes, assessed before they are left on, and set to the more restrictive option where no decision has been made.
8. Vendors
Third parties that hold or can reach information on our behalf are inventoried in the Schedule of Third-Party Services. Before a vendor is introduced we consider what information it will reach, what its terms say about handling that information, and whether an agreement — a business associate agreement, a data processing agreement — is required before it is used.
9. Incidents
Suspected and actual security incidents are handled under the Incident Response Plan. Where an incident involves data we hold on a client’s behalf, the notification obligations in the Data Processing Agreement apply, including the rule that the client — not us — decides whether an incident is legally reportable.
10. Review
The Coordinator reviews this programme at least annually, and sooner after a material change to our systems, our services, the threat landscape, or applicable law. Each review records what changed, what was assessed, and what remains open.
Prior versions of this policy stay available at their own dated addresses.