Security
BookSemantic maintains proportionate technical and organisational safeguards across identity, application, payments, storage, and operations. This summary is not a certification or a promise that risk can be eliminated.
Identity and access
Access is authenticated and authorised according to account ownership, collaborator role, and subscription entitlement. Access is reviewed and limited to what is needed for the requested function.
Application and data
We use layered controls for data handling, transmission, input and file processing, service credentials, recovery, and operational monitoring. Detailed configurations are intentionally not published because doing so could weaken protection of customers and the service.
Payments and abuse protection
Payment information is handled by a specialist payment provider. We maintain transaction reconciliation, abuse prevention, and account-level controls appropriate to subscriptions and usage-based credits.
Regional operations and incidents
Service resources may be assigned to European or US deployments as explained in the Privacy Notice; region selection does not by itself prevent every international transfer. Monitoring, recovery, and incident procedures support response. Where a personal-data breach meets the legal threshold, the controller follows applicable notification duties, including the UK GDPR 72-hour reporting requirement where feasible.
Your responsibilities
Use a unique password, protect your email and devices, review collaborator access, keep independent exports of important work, and report suspected compromise promptly to support@booksemantic.com.
Use this summary without mistaking it for a guarantee
The safeguards described above are the published security summary. The guidance below helps you read that summary, organize a question and describe a concern. It does not introduce additional controls, a certification, a service guarantee or new reporting terms. The Privacy Notice and Terms of Use remain the places to read the corresponding policy and contractual statements.
Identify the question you are trying to answer
Security questions often begin with an ordinary workflow: inviting a reviewer, uploading a reference, paying for a plan or returning to a draft after an interruption. Name the action first. Then read the relevant part of the summary rather than treating every concern as the same technical problem. Account access, content permissions and payment records involve different questions.
For example, if a collaborator cannot open a book, the useful question may concern the invitation and assigned role. If you see a billing entry you do not recognize, describe the entry and its date without sending card details. A clear account of the observation makes the question easier to understand than a broad statement that something seems insecure.
Keep account access distinct from editorial approval
Giving someone a role in a writing project and approving their editorial suggestion are separate decisions. When reviewing access, consider who needs to participate and what work they are doing. When reviewing the manuscript, decide whether a change belongs in the book. Neither decision should be inferred merely because a person has contributed a useful comment.
The same distinction helps when preparing a handoff. Identify the book, the draft and the intended recipient before sharing work through the available process. Keep your own record of the version you meant to share. This is practical project guidance, not a statement that a particular sharing action has occurred or that a recipient has been verified.
Describe an observation without exposing more information
If you contact support about a suspected problem, explain what you expected, what you observed and approximately when it happened. Include the relevant page or feature name and any non-sensitive error wording. Distinguish something you saw once from a behavior you can describe consistently. You do not need to establish the technical cause before asking a clear question.
Before attaching a screenshot, check what else it contains. Remove passwords, sign-in links, payment details and private information unrelated to the concern. An image of an error may also reveal a manuscript passage, another person’s email address or a private browser tab. A cropped, redacted example can communicate the issue without sending the whole working environment.
Use the published contact and policy routes
Use the support address printed above for a suspected compromise and the contact routes in the Privacy Notice for a privacy question or rights request. Read those pages for their stated procedures and commitments. This guide does not announce an additional emergency service, a bug-bounty program or a guaranteed response interval.
Be cautious about a message that asks you to move a support conversation to an unfamiliar payment page or provide a password. Return to the website and its published contact information when you need to check where a request belongs. Do not include a sign-in secret in an ordinary description of a problem.
Keep the working copy and the review record understandable
An independent export of important work can be useful when reviewing what changed, as the responsibilities section above notes. Give the file a meaningful name and record which draft it represents. If you are comparing versions after an interruption, identify the passages in question rather than assuming the newest-looking filename contains the intended text.
When the immediate question is resolved, retain only the project notes you need for your work and follow the applicable notice and your own obligations for any personal information involved. A short record of the decision can help you avoid repeating an uncertain action. It is not evidence that risk has disappeared, and it does not replace reviewing the current published guidance.