Editorial standards
How ShadowLock content is made
ShadowLock publishes product documentation, security guidance, compliance mappings, research, and educational content for MSPs and IT teams. This page describes what those claims rest on, how we keep product fact separate from interpretation, and how the content is kept current.
What content is based on
Four inputs, and nothing else
ShadowLock is a small, founder-led company. Content is produced in-house by the people who build the product, and every claim traces back to one of four things:
Direct product knowledge
Anything stated about what ShadowLock does, sees, blocks, stores, or cannot do comes from the software itself and from the security architecture document, not from a positioning deck. Where the product has a limitation, we would rather write the limitation down than route around it.
Primary technical and vendor documentation
Claims about third-party tools come from that vendor's own documentation, terms, DPA, or admin console behaviour, cited and linked. Where a vendor has changed a data-handling term, we cite the term, not a news summary of it.
Recognized security and AI governance frameworks
Compliance and governance material is mapped to published frameworks: the NIST AI Risk Management Framework, ISO/IEC 42001, SOC 2, the HIPAA Security Rule, GDPR, and the EU AI Act. We describe what a framework requires and link to it, rather than paraphrasing it into a checklist that cannot be traced back.
Practical MSP and security experience
Operational guidance, such as how to sequence a rollout or what to tell a client, comes from experience building and running security products in the MSP channel. When a recommendation is a judgement call rather than a documented requirement, the sentence says so.
Editorial principles
The rules we hold the content to
Separate product fact from interpretation
A statement about what ShadowLock does is verifiable and we treat it as a commitment. A statement about what an MSP should therefore do is interpretation, and it is written so a reader can tell the difference within the sentence. We do not present an opinion as a finding.
Cite sources by name and link to them
Every statistic, framework reference, or third-party claim carries a named publisher and a link to its page. If it cannot be cited, it does not get published. We do not currently publish first-party telemetry; if we do, it will come with a sample size, an observation window, a methodology, and its limitations.
No sponsored or paid content
No paid placements, no sponsored posts, no link insertions, no guest contributions. Competitor comparisons name where a competitor is genuinely stronger, and name our own trade-offs and gaps.
Update as the product and the landscape change
Content is reviewed and revised as ShadowLock changes, as the AI vendor landscape shifts, and as the relevant standards are updated. Buyer's guides, statistics posts, and the living trackers are reviewed at least annually and more often when something material changes. Every post shows its date.
Compliance material is not legal advice
Posts covering HIPAA, SOC 2, GDPR, the EU AI Act, and cyber insurance describe patterns, requirements, and frameworks. They are not legal advice, and we recommend legal review before any organization adopts a specific control or interpretation.
Claims about the product
The Trust Center is the authoritative version
Marketing pages and blog posts necessarily summarise. Where a claim concerns ShadowLock's own security architecture, what data leaves an endpoint, tenant isolation, encryption, sub-processors, retention, personnel access, or breach notification, the Security & Trust Center is the source of record and this site defers to it. It is published in full, including where ShadowLock does not yet hold a certification a buyer may require.
Read the Trust CenterPrimary sources
The sources we cite most
Statistics and framework references are attributed to a named publisher and linked to the original. The sources that recur across our content:
- • Gartner: survey research on shadow AI and AI governance among security and risk leaders
- • Microsoft Work Trend Index: annual workplace AI adoption research
- • Cyberhaven: endpoint research on sensitive data flowing to AI tools
- • IBM Cost of a Data Breach Report: annual breach economics research
- • NIST AI Risk Management Framework: US federal framework for AI risk
- • ISO/IEC 42001: international standard for AI management systems
- • US HHS HIPAA guidance: Privacy Rule and Security Rule reference
- • EU AI Act: European regulation of AI systems
- • EU-US Data Privacy Framework: post-Schrems II transfer framework
- • Netskope Threat Labs cloud and threat reports
- • Vendor documentation, enterprise terms, and DPAs for any third-party AI tool we describe
Corrections
Found a factual error?
The AI vendor landscape changes quickly and published research is superseded. If you spot a factual error, an outdated statistic, a vendor behaviour that has changed, or a citation that needs updating, tell us. Corrections are treated as a priority and the post is updated with a note saying what changed.
Send a correctionFrequently asked
About our editorial process
Who writes ShadowLock's content?
All of it is produced in-house by the people who build the product, and published under the ShadowLock byline rather than a personal one. ShadowLock is a small, founder-led company; the byline reflects that the company stands behind the claim, not that a named expert has been assigned to it. We do not accept guest posts, sponsored posts, or ghostwritten contributions.
What sources does ShadowLock cite?
Primary sources: Gartner research, the Microsoft Work Trend Index, Cyberhaven endpoint research, Netskope Threat Labs, the IBM Cost of a Data Breach Report, the NIST AI Risk Management Framework, ISO/IEC 42001, US HHS HIPAA guidance, the EU Commission on the AI Act and the Data Privacy Framework, and vendor documentation and terms for any third-party tool we describe.
How do I know whether something is a product fact or an opinion?
Claims about what ShadowLock does, stores, or blocks are product facts, and the authoritative version of each one is in the Security & Trust Center, which documents the architecture, data inventory, sub-processors, retention, and personnel access. Recommendations about how to run an AI governance program are interpretation, and are written as such.
How often is content reviewed and updated?
Buyer's guides, statistics posts, and the regulation, insurance, and incident trackers are reviewed at least annually and updated sooner when the underlying landscape changes materially. Foundational definitions and framework guides are reviewed annually. Every post displays its publication date, and significant updates are noted inline.
How do I report a factual error?
Use the contact form. Corrections are treated as a priority and the post is updated with a brief note describing what changed. This applies to outdated statistics, superseded vendor behaviour, and citations that need updating as much as it does to outright errors.
Questions about something we published?
Corrections, press enquiries, research questions, or anything about the product. Every message is read.