The short answer
Artisan sells an AI BDR that sends email and makes calls to people who did not ask to hear from you. That single fact is what makes its security and procurement posture worth more scrutiny than a normal SaaS purchase, because the data flowing through it is mostly personal data about third parties who have no relationship with your company.
We went through everything Artisan publishes on 9 September 2026: the trust centre, the data processing agreement, the pricing page and the company pages. The headline is that Artisan is better documented than the category average and worse at showing it.
| What a security review asks | What we found |
|---|---|
| Is there a SOC 2? | Yes, Type 2, and the trust centre hides it. See below |
| Is there a real DPA? | Yes, and a substantial one. Updated 17 May 2026 |
| Breach notification window? | 48 hours, committed in the DPA |
| Can we audit them? | In writing only. No inspection right in practice |
| Is our data used to train models? | No, and it is flowed down to their AI subprocessors |
| Who carries the GDPR risk? | You do. Explicitly, in several places |
| What does it cost? | Not published. Tiers are sized by lead volume |
The SOC 2 problem is the opposite of the usual one
Normally the story with a vendor and a SOC 2 is that marketing claims one and the trust centre cannot support it. Here it runs the other way, and it is worth walking through carefully because the difference matters to a real company.

Artisan’s pricing page states plainly: enterprise-grade security, SOC 2 Type II certified, SSO and SAML, audit logs and built-in compliance controls.
Artisan’s trust centre is the surface a security reviewer actually visits. Its self-assessment section reads, in full: “We are working on our security compliance. We can provide completed questionnaires upon request.” We searched the rendered page for SOC 2, ISO 27001, GDPR, CCPA, HIPAA and PCI. Not one of them appears. The only document listed under Reports is a penetration test.
The certification is there. The page just does not draw it.
A trust centre is a rendered view of structured data, so we looked at the data the page serves itself from. It contains a SOC 2 Type 2 record marked complete, with the auditor named as Sensiba, alongside a second SOC 2 Type 2 record marked in progress and a completed CAIQ v4.0.3 self-assessment.
Sensiba is a real firm. Its own site describes it as accounting, assurance and business advisory, which is the kind of practice that signs SOC 2 reports.
The most natural reading of two records is a completed Type 2 plus a further observation window underway, which is simply how Type 2 works: it certifies controls over a period, so it recurs. We are not asserting that as fact, because we cannot see either report. What we can say is that the certification data exists, says complete, and names an auditor, and that none of it renders on the page.
Saru says: This is a configuration problem wearing the costume of a red flag. The compliance section of the trust centre is not switched on, so the strongest thing Artisan has to say about its security is the one thing a visitor cannot read.
What sits behind the access request, and what to ask for by name
The trust centre gates its documents behind a request, which is normal, but it does list what exists. Knowing the names is worth something, because a request for “your security documentation” gets a slower and vaguer answer than a request for four named files.
Under reports there is a penetration test. Under product security, a data security document and a logging and monitoring policy. Under legal, the subprocessor list. Then a full set of named policies: acceptable use, access control, asset authorization and monitoring, asset management, awareness and training, backup, business continuity and disaster recovery, change management, and vulnerability management.
That is a more complete policy set than most companies of roughly fifty people have written down at all, and it is the strongest evidence on the trust centre that the security work is real rather than aspirational. Ask for the subprocessor list on day one, separately from the rest. It is the shortest document, it is the one most likely to contain a name your own compliance position has an opinion about, and it is the only one that changes without you being consulted, on thirty days notice.
Why this costs Artisan real deals, and what it means for you
Put yourself in the security reviewer’s chair. You are told the vendor is SOC 2 Type II certified. You do what you are supposed to do, which is not take marketing’s word for it, and you go to the trust centre. It tells you they are working on their security compliance and offers you a pentest report.
The reasonable conclusion from that is that the marketing page is overstating things. It is the wrong conclusion, and it is the one the evidence in front of you supports.
The same applies to AI assistants, which increasingly answer exactly this question. An assistant summarising Artisan’s security posture reads the rendered trust centre, not the payload behind it, and reports that Artisan is working towards compliance. A certification nobody can see does no work at all.
Faz says: If you are evaluating Artisan, ask for the SOC 2 Type 2 report and the observation period it covers, and do not read the trust centre as an answer either way. If you work at Artisan, this is a checkbox in SafeBase and it is costing you security reviews.
The DPA is the best thing Artisan publishes
The data processing agreement was last updated 17 May 2026 and runs to roughly forty three thousand characters. It is specific where most vendor DPAs are decorative, and several of its terms are better than the category norm.
| Term | What Artisan commits to | Read |
|---|---|---|
| Breach notification | Initial notice without undue delay and no later than 48 hours after becoming aware | Firm, and tighter than “without undue delay” alone |
| Subprocessor changes | 30 days prior notice before adding or replacing one | Buyer-favourable. Gives you time to object |
| AI training | Will not train, fine-tune, benchmark or improve models on your personal data | Strong, and flowed down to their LLM providers |
| Deletion | Delete or return all customer data on termination, backups isolated then deleted | Standard and clearly written |
| Transfers | Standard Contractual Clauses, EU 2021/914 | Expected. Present and correct |
| California | Certifies it will not sell or share California personal information | The CPRA language, done properly |
| Audit rights | Exercised by written responses on a confidential basis | The weak one. See below |
Two things in there that procurement should catch
First, the DPA is incorporated into your agreement upon request, not automatically. It says so in its own opening. If nobody on your side asks for it, you may sign a contract that the DPA does not form part of. That is a thirty second fix and an expensive thing to discover later.
Second, the audit right is not what it sounds like. The DPA says you exercise it by instructing Artisan to comply with the audit measures described in the agreement, which resolves to written responses to reasonable requests, provided confidentially. There is no practical right of inspection. That is common for a company of this size and it is still a thing your legal team should see before they read the word “audit” and tick the box.
The subprocessor list itself lives on the trust centre and is gated behind an access request, so you cannot see who processes your data until you ask. Worth requesting on day one rather than at contract stage, because it is the list most likely to contain a surprise.
Section 12 is where the risk gets handed to you
The DPA has a section on AI processing and outbound communications that most competitors do not have at all. Artisan deserves credit for writing it. Then you should read it very carefully, because it is a clear and deliberate allocation of risk, and the risk lands on the customer.
You are the controller, and Artisan does not check legality
Artisan processes outbound communications data as a processor acting solely on your instructions. You are the controller. In its own words, Artisan only suggests recipients based on your criteria, does not determine the content beyond executing your configured parameters, and does not assess the lawfulness of any individual communication.
That last clause is the one to sit with. The product finds strangers and emails them. Whether emailing that particular stranger, in that particular country, on that particular basis, is lawful is not a question the vendor is answering for you.
The Article 13 and 14 obligation lands on you, including for bought data
Under GDPR, if you process someone’s personal data you generally have to tell them. Artisan’s DPA states that the customer is fully responsible for providing the transparency notices required under Articles 13 and 14 to all data subjects whose data is processed using the service, and it specifically includes contact data provided by third parties.
Read that against the platform claim of 250 million verified B2B contacts. If you prospect into a European contact from a purchased list, the notice obligation to that person is yours. Artisan will provide reasonable technical assistance on request. It will not do it for you.
The same applies to lawful basis. You are responsible for keeping consent records and legitimate interest assessments, and the DPA says directly that Artisan has no obligation to store or verify them on your behalf.
Saru says: An LIA is not a formality here. If your basis for cold outbound is legitimate interest, somebody has to have written that assessment down before the first send, and the DPA has just told you it will not be Artisan.
The Article 22 disclosure is unusually honest, and easy to miss
The DPA states that the service involves profiling of data subjects under GDPR Article 4(4), but is not designed to automate decisions with legal or similarly significant effects under Article 22. It then adds a sentence most vendors would have left out: “Artisan does not represent that its Services comply with Article 22 safeguards.”
That is a candid disclaimer rather than a defect. Article 22 is about decisions made about a person by automated means, and an AI that decides who to contact is nearer to that boundary than a spreadsheet is. Artisan is telling you where its representations stop. Your data protection officer should be the one deciding what to do with that, and they can only do it if somebody surfaces the sentence.
Resilience, hosting and the things stated as intentions
The trust centre publishes a risk profile. Both numbers are worth knowing before an incident rather than during one.
Recovery time objective: 24 to 48 hours. Recovery point objective: 24 to 48 hours. The second is the one people skip past. An RPO of 24 to 48 hours means that in a disaster the recovery target allows for up to two days of data loss. For a system holding your sequences, replies and booked meetings, decide whether that is acceptable, and if it is not, say so during negotiation rather than after.
Hosting is described only as a major cloud provider, unnamed. If your own compliance position depends on data residency, that is a question to ask directly, because the trust centre does not answer it.
Three sections are written in the future tense
Reading a trust centre closely means noticing what is promised rather than described. Three entries here are aspirational: app security says Artisan is putting together a program to monitor internal apps; security grades says it will post grades from public rating agencies when they become available; and the self-assessment section, as covered above, says compliance work is ongoing.
None of these is alarming for a company of roughly fifty people that has raised twenty five million dollars. All three are normal for the stage. They are worth reading accurately rather than skimming, because the same page also lists a genuine pentest report and a full set of named policies covering access control, change management, vulnerability management, backup and business continuity. The substance is ahead of the presentation, which is the theme of this whole evaluation.
The security controls are attached to the top tier
Artisan publishes no price, and how its plans are structured is covered on our Artisan pricing page, which is where that question belongs. One thing on that page is a security question rather than a pricing one, so it belongs here instead.
The plan table attaches advanced security controls and audit logs to the Enterprise tier specifically. The security summary further up the same page lists SSO, SAML and audit logs as though they were general to the product. Those two statements are not consistent, and which one is true decides whether a security review passes or stalls.
Establish early which tier your SSO requirement sits in. Discovering that single sign-on is Enterprise-only after you have budgeted for the entry plan is an expensive conversation to have with your own finance team, and it is the most common way a security review turns into a renegotiation.
The company behind it
Artisan discloses considerably more about itself than most vendors in this category, which makes the viability question easier to answer.
| Disclosed | Detail |
|---|---|
| Investors | HubSpot Ventures, Y Combinator, Soma Capital |
| Funding | Its newsroom links coverage stating $25 million raised |
| Size | 50+ team members across product, engineering and go-to-market |
| Locations | San Francisco and New York, plus distributed staff |
| Leadership | A third-time founder as CEO, previously a marketing agency |
For a three-year commitment the relevant reading is that Artisan is venture-backed, small, and growing, with an investor list that includes the venture arm of a CRM company its product integrates with. None of that is a concern by itself. It does mean you are buying from a company whose shape will change during your contract term, so renewal protections and data export terms matter more here than they would with an established vendor.
The eight questions to send before you sign
| # | Ask | Why |
|---|---|---|
| 1 | The SOC 2 Type 2 report and the period it covers | Claimed on pricing, invisible on the trust centre |
| 2 | Confirm the DPA is incorporated into our agreement | It applies on request, not by default |
| 3 | The subprocessor list, now | Gated. It is where surprises live |
| 4 | Which cloud provider and which region | Stated only as “major cloud provider” |
| 5 | Whether the 24 to 48 hour RPO can be improved | That is up to two days of data loss |
| 6 | Are SSO, SAML and audit logs Enterprise-only | The page implies yes, the blurb implies no |
| 7 | Who writes our Article 13 and 14 notices | The DPA says you do |
| 8 | Your DPO’s view on the Article 22 disclaimer | Artisan explicitly does not represent compliance |
The overall read
Artisan is a better-documented vendor than its trust centre makes it look. The DPA is genuinely strong, the AI training position is clear and flowed down to subprocessors, the breach window is committed in hours rather than adjectives, and the certification appears to exist.
The two real cautions are not about Artisan’s competence. One is presentational and fixable in an afternoon, and it is currently telling every security reviewer the wrong thing. The other is structural: this product does something legally sensitive on your behalf, and the paperwork is unusually clear that the legal exposure is yours. That is a defensible position for the vendor to take. It is only a problem if you sign without noticing it.
How we did this and what we did not do
We have not used Artisan. This is a security and procurement evaluation built from published material, not a product test. Everything above was read from Artisan’s own pages on 9 September 2026 by following their navigation, including the trust centre and the full data processing agreement.
We did not request access to the gated documents, so we have not read the pentest report, the subprocessor list or the SOC 2 report itself, and we are not characterising their contents. Where we could not establish something we have said so, rather than treating an absence of evidence as evidence of absence, which on the SOC 2 question would have produced exactly the wrong answer.



