Information Security Policy

This policy establishes the requirements for identifying, mitigating and monitoring information-security risks to the confidentiality, integrity and availability of Shofield information and services. It applies to shofield.ai, platform.shofield.ai, supporting business systems, source code, cloud services, employee and contractor devices, and information processed for customers or connected accounts.

Employees, contractors and service operators must follow this policy when accessing Shofield systems or information. Controls must be appropriate to the information, business activity and deployment. Customer-managed systems and supplier-operated infrastructure require documented allocation of responsibilities; using a supplier does not remove Shofield’s responsibilities.

Management is accountable for information security and must approve the policy, assign control responsibilities, review material risks, authorize time-limited exceptions and coordinate incident response. Technical work may be delegated, but risk acceptance remains a human management decision.

Approval, version history, assigned responsibilities and review records must be maintained internally. Personnel must acknowledge the policy before receiving production or sensitive-data access and after material changes. Security requirements must inform procurement, development, releases and significant business changes.

Maintain an inventory of important services, data stores, integrations, devices, identities and suppliers, including owners, data sensitivity and dependencies. Document how sensitive information enters, moves through and leaves each relevant workflow, including logs, backups and AI services.

Perform a risk assessment before a material deployment, new sensitive-data use or significant supplier change, and after incidents or material threat changes. Maintain a risk register recording the affected asset, threat, likelihood, impact, existing evidence, treatment, owner and review date. Review open risks regularly; absence of evidence must not be treated as proof that a control exists.

Choose and record whether to reduce, avoid, transfer or accept each material risk. Every treatment must identify an accountable owner, action, due date, validation evidence and residual risk. Risk acceptance must be explicit, time-limited and reviewed; it cannot override applicable law, a provider requirement or a binding contractual duty.

High-impact changes must receive proportionate testing, approval and a rollback plan. Security-sensitive production changes must remain traceable to the approved change. Unverified safeguards required for a new sensitive-data workflow must be verified before enabling that workflow. Do not replace working systems merely to satisfy a documentation exercise.

Use unique identities, least-privilege access and server-side authorization. Privileged access and access to systems processing sensitive financial information must use multi-factor authentication. Review access regularly, revoke unnecessary access promptly and restrict service accounts to their approved functions. Support or impersonation functions must not bypass private-data boundaries.

Production access must use approved, inventoried devices with supported software, security updates, screen locking and appropriate endpoint protection and disk encryption. Protect devices and recovery material against loss and unauthorized physical access. Evaluate supplier physical-security responsibilities for hosted infrastructure; do not claim Shofield operates supplier data centres.

Classify information as public, internal, confidential or restricted. Authentication secrets and sensitive financial records require restricted handling. Collect only information needed for a permitted purpose. Use modern encryption in transit and at rest for sensitive information, with separately controlled keys, access permissions and recovery arrangements.

API credentials, long-lived connection tokens and encryption keys must remain in approved server-side secret storage. Do not place them in source control, browser persistence, URLs, logs, analytics, AI prompts or shared documentation. Separate test and production environments. Restrict exports, redact unnecessary identifiers and validate tenant boundaries on every relevant request.

Review security-sensitive code, check dependencies and scan for exposed secrets and vulnerabilities at defined intervals and after material changes. Assess, prioritize and remediate findings according to risk. Record exceptions and confirm fixes through retesting. Only scan systems within an approved scope; supplier infrastructure requires the supplier’s authorization.

Assess material suppliers before granting access and when their service or data use changes. Verify relevant access, retention, security, incident and deletion arrangements for the actual product and account. A supplier’s certification does not certify Shofield.

Treat external documents, messages, websites and transaction descriptions as untrusted input. AI agents must use narrowly authorized tools and must not determine their own permissions or accept security risks. Secrets must never enter model context. Sensitive information may enter an AI workflow only when its purpose, permissions and provider arrangements have been approved. Consequential or destructive actions require authorized human approval.

Maintain proportionate security logging and alerting for important authentication, permission, configuration, data-access and integration events. Include suspicious activity, unusual exports and abnormal automated usage where applicable. Logs must exclude credentials and unnecessary sensitive content, and must be protected against unauthorized access or alteration.

Assign an alert recipient and backup coverage, verify that alerts reach them and record the review cadence. Review alerts and monitoring health, create investigation records and escalate material findings. An empty or failed feed must not be reported as “no incidents”.

Maintain an incident-response procedure covering triage, containment, evidence preservation, investigation, recovery and lessons learned. Coordinate required notifications with affected customers, providers and relevant authorities within applicable obligations. Do not promise an investigation is complete before the evidence supports that conclusion.

Define recovery priorities for critical services, protect backups and test restoration at risk-appropriate intervals. Restoration must preserve security controls and must not reintroduce revoked access or information already subject to a valid deletion decision.

Maintain an approved retention schedule by data category and purpose. Remove or anonymize information when its approved purpose and retention period end, subject to documented legal holds and other applicable obligations. Verify deletion, token revocation and cessation of future collection as distinct actions. Explain any continuing restricted backup retention rather than promising immediate deletion from every copy.

Maintain private records of risk reviews, access decisions, security checks, remediation, incident exercises and recovery tests. Review this policy at least annually and after material changes. Publish an approved public version and keep sensitive configurations, vulnerabilities and incident records private.

Questionnaire answers and public security statements must describe verified practices within their actual scope. Policy adoption is not proof that every requirement has been implemented. This policy does not assert ISO 27001 certification, SOC 2 assurance, universal regulatory compliance, a 24-hour security operations centre or guaranteed security.

For information-security enquiries or to request a secure channel for a security report, contact Legal@shofield.ai. Provide only a brief, non-sensitive description and your contact details. Do not send passwords, API keys, tokens, bank records or sensitive evidence by ordinary email. This policy does not authorize security testing, access to other users’ data or disruption of services.

Approval and review records are maintained internally. This policy is reviewed at least annually and after material changes. Supporting operating procedures and risk and evidence records remain private.