Spirion finds your sensitive data. What protects it after you find it?
PKWARE vs Spirion is the comparison that surfaces a specific gap. Discovery and classification map the problem. Persistent file-level encryption protects the data. If you have one and not the other, the files Spirion finds stay readable to anyone who gets them.
Discovery without protection is just a list of problems.
Spirion does real work. That's the problem with the comparison. It makes it easy to assume the data security box is checked.
Finds and labels the sensitive data.
Sensitive data discovery across endpoints, file shares, cloud storage, and relational databases. Persistent classification labels that follow the data when it moves. Remediation playbooks for quarantine, multi-pass secure deletion, redaction, and masking. Spirion maps where regulated data lives and standardizes the policies that act on it.
Protect the file in place.
Spirion's native remediation actions are subtractive. They remove the data (delete, quarantine) or hide it (redact, mask). The files Spirion classifies but doesn't quarantine or destroy sit on the file system in plaintext, labeled but readable. If they're exfiltrated through valid credentials, an unmanaged share, or a misconfigured cloud sync, the contents leave in the clear.
Spirion tells you the file contains a Social Security number. It doesn't change what someone can do with the file once they have it. PK Protect encrypts the data itself. The file stays protected when it's emailed, copied to a USB drive, uploaded to an unmanaged cloud, or exfiltrated by an attacker who already has admin rights.
PKWARE vs Spirion: side by side.
What each platform covers, and where the gaps are.
Data Discovery & Classification
| Capability | Spirion | PK Protect |
|---|---|---|
| Sensitive data discovery across endpoints, file shares, and cloud | ✓ | ✓ |
| Persistent contextual classification (sensitivity, purpose, regulatory, custom) | ✓ | Partial |
| Structured database column-level discovery | ✓ | ✓ |
| Dynamic label updates when data is modified | ✓ | Partial |
| Mainframe (z/OS) data discovery | ✕ | ✓ |
Encryption & Data Protection
| Capability | Spirion | PK Protect |
|---|---|---|
| Native persistent file-level encryption | ✕ | ✓ |
| Encryption that travels with the file after exfiltration | ✕ | ✓ |
| Encryption across legacy and on-premises environments | ✕ | ✓ |
| Mainframe (z/OS) encryption | ✕ | ✓ |
| Data masking and redaction | ✓ | ✓ |
| Multi-pass secure data erasure (NIST/DoD/Gutmann) | ✓ | ✕ |
| FIPS 140-validated cryptographic modules | ✕ | ✓ |
| Discovery, classification, and encryption in one platform | ✕ | ✓ |
Threat Detection & Access Governance
| Capability | Spirion | PK Protect |
|---|---|---|
| DSAR fulfillment and privacy preference workflows | ✓ | ✕ |
| Behavioral access analytics and insider threat detection | ✕ | ✕ |
| Audit logging of remediation actions | ✓ | ✓ |
Compliance Documentation
| Capability | Spirion | PK Protect |
|---|---|---|
| PCI DSS 4.0.1 Req 3.5.1 (PAN rendered unreadable) | ✕ | ✓ |
| HIPAA encryption of ePHI at rest (addressable) | ✕ | ✓ |
| GLBA encryption of customer information (16 CFR §314.4(c)(3)) | ✕ | ✓ |
| State breach notification safe harbor for encrypted data | ✕ | ✓ |
| Audit-ready policy console documentation | ✓ | ✓ |
Deployment & Environment Coverage
| Capability | Spirion | PK Protect |
|---|---|---|
| Windows endpoints and servers | ✓ | ✓ |
| Microsoft 365 and SharePoint | ✓ | ✓ |
| Cloud storage (S3, Azure Blob, Google Cloud) | ✓ | ✓ |
| Citrix and VDI environments | Partial | ✓ |
| On-premises file shares and legacy file systems | ✓ | ✓ |
| Mainframe / z/OS | ✕ | ✓ |
| IBM i, AS/400, and POS environments | ✕ | ✓ |
✓ Full capability. Partial means limited scope. ✕ means not supported. Spirion capabilities reflect publicly documented features from current Spirion and archTIS product datasheets, the Privacy-Grade framework checklist, and the archTIS website. Independent verification required before publishing.
The encryption sister product is real. It doesn't close the architectural gap.
Spirion is now part of archTIS Limited, the Australian information security company that completed its acquisition of Spirion in October 2025. archTIS also sells NC Protect, an attribute-based access control product for Microsoft 365 environments, with NC Encrypt as an add-on module that applies encryption inside SharePoint Online, OneDrive, Teams, Exchange, and SharePoint Server. That integration is real. It doesn't close the architectural gap.
The full deployment requires three product subscriptions (Spirion, NC Protect, NC Encrypt) plus Microsoft 365 E5 Information Protection and Governance licensing for MPIP-applied encryption to function. Operating it means at least two admin consoles, Spirion's Sensitive Data Platform and archTIS NC Protect, plus the Microsoft Purview admin center for the underlying labels. The cross-product integration between Spirion classification and NC Protect protection policies shipped in NC Protect V9 in November 2025.
Coverage still ends where Microsoft 365 ends. On-premises file shares outside SharePoint Server, mainframe systems, IBM i, POS environments, custom applications, legacy file types, and any data that doesn't route through Microsoft Purview Information Protection sit outside that coverage.
PK Protect runs alongside both. It uses Microsoft Purview labels where they exist and applies persistent file-level encryption across every environment they don't reach, in one platform, with one admin console.
Your frameworks are asking about encryption specifically.
Discovery and classification map the data. Encryption protects it. The frameworks are written in terms of the second one.
Requirement 3.5.1. PAN rendered unreadable wherever stored.
PCI DSS 4.0.1 Requirement 3.5.1 specifies that stored Primary Account Numbers be rendered unreadable using one of four approaches: keyed cryptographic hashes, truncation, index tokens with securely stored pads, or strong cryptography with associated key management. Tools that classify data as containing PAN do not satisfy this requirement on their own.
Encryption of ePHI at rest is an addressable specification.
Under 45 CFR §164.312(a)(2)(iv), encryption of ePHI is an addressable implementation specification. Addressable means a covered entity must implement encryption, or document a specific equivalent alternative and justify why. The practical standard for HHS audits is encryption.
Encryption of customer information in transit and at rest.
The FTC's updated Safeguards Rule at 16 CFR §314.4(c)(3) requires encryption of customer information in transit over external networks and at rest. The rule applies to non-banking financial institutions and to higher education institutions that participate in federal financial aid programs. Schools and lenders carrying unencrypted student or customer data on endpoints, servers, or shared storage carry direct regulatory exposure.
Encrypted data may not trigger notification.
All 50 states, the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands have data breach notification laws. Most include a safe harbor that excludes encrypted data from the definition of a breach requiring notification. Specific requirements vary. Some states require "generally accepted" encryption (California, Colorado, Maine). Some require 128-bit minimum (Massachusetts, Rhode Island). Some specify that the safe harbor only applies if the encryption key wasn't acquired with the data (New York). Discovery and classification don't qualify. Encryption that renders the data unreadable does.
Why well-run data security teams carry this gap.
There's a rationalization that runs through mature data security organizations. They've invested in Spirion. They know where the sensitive data lives. They have classification labels, remediation playbooks, and reports they can show an auditor. The data is mapped. The instinct is that the problem is solved, and that instinct makes sense. All of it represents real work and real risk reduction.
The rationalization breaks at one specific place. The remediation menu.
Spirion's protection actions are subtractive. Quarantine moves the data. Secure deletion removes the data. Redaction removes the sensitive parts. These are real actions and they work for some data. They don't work for data the business needs to keep, in the format it's already in, accessible to the people who already use it. For that data, the only path Spirion ships natively is to leave it where it is, labeled and reported on, but still readable.
PK Protect takes the next step. It finds the sensitive data, classifies it, and encrypts it by policy. That encryption is file-level. It lives in the file, not in the network path. A file encrypted by PK Protect stays encrypted when it's emailed, uploaded to SharePoint, copied to a USB drive, or exfiltrated by a threat actor who spent six months building access. Authorized users open it the same way they open any other file. Everyone else sees ciphertext.
Spirion stays in place. It keeps doing what it does well. PK Protect adds the action that Spirion's remediation menu was never built to include.
Every POV is scoped to your environment.
Encryption projects fail when they're deployed against assumptions instead of evidence. Our process is built to surface every workflow that matters before production.
Start with what you already know.
If you're already running Spirion, bring the inventory. You know where the sensitive data is. We map that to the file types, repositories, applications, and user workflows that need to stay intact. Citrix, VDI, analytics environments, legacy file systems, mainframe. Whatever's actually in your stack.
Success criteria.
You define what success looks like before we start. Specific workflows that must continue to work. Specific compliance evidence that must be producible. Specific deployment timelines that must hold. Those criteria become the gate.
POV in your environment.
PK Protect deploys in a scoped test environment that mirrors production. We validate discovery, encryption, key access, audit logging, and every workflow on the success criteria list.
Decision.
If every criterion is met, you have evidence. If anything fails, you know before any commitment. The POV is the test. Not the sales pitch.
What buyers ask before they decide.
No. Spirion is a sensitive data discovery, classification, and remediation platform. Its native remediation actions include quarantine, multi-pass secure deletion, redaction, and masking. Encryption is referenced in archTIS materials as a capability of the NC Protect product line (NC Encrypt add-on), not as a native capability of Spirion itself. Files that Spirion classifies but doesn't quarantine, delete, or redact remain in plaintext on the file system.
No. PCI DSS 4.0.1 Requirement 3.5.1 requires stored PAN to be rendered unreadable using one of four specific approaches: keyed cryptographic hashes, truncation, index tokens, or strong cryptography. Spirion identifies and classifies PAN. Rendering the PAN unreadable wherever it's stored requires a dedicated encryption or tokenization solution.
No. They solve different problems. Spirion handles discovery, classification, and subtractive remediation: quarantine, deletion, redaction, masking. PK Protect handles persistent file-level encryption. Spirion tells you what data you have and where it lives. PK Protect changes the state of the files so they're unreadable to anyone without authorization, in any environment, without removing them from the workflows that depend on them. Both stay in place. Spirion maps the exposure. PK Protect closes it.
Inside Microsoft 365, with limits, and through two additional product subscriptions on top of the Spirion license. NC Protect is archTIS's attribute-based access control product for Microsoft environments, and the NC Encrypt add-on module applies encryption within SharePoint Online, OneDrive, Teams, Exchange, and SharePoint Server. The full deployment requires three product subscriptions (Spirion, NC Protect, NC Encrypt) plus Microsoft 365 E5 Information Protection and Governance licensing for MPIP-applied encryption to function. Operating it means at least two admin consoles plus the Microsoft Purview admin center. Coverage still ends where Microsoft 365 ends: on-premises file shares outside SharePoint Server, mainframe systems, IBM i, POS systems, custom applications, and any data that doesn't route through Microsoft Purview Information Protection sit outside that coverage. PK Protect applies persistent file-level encryption across every environment, in one platform, with one admin console.
HIPAA's Security Rule designates encryption of ePHI as an addressable implementation specification under 45 CFR §164.312. Addressable means a covered entity must implement encryption, or document a specific equivalent alternative and justify why. In practice, covered entities and business associates who cannot document a justified equivalent face direct audit exposure. Encryption is the de facto standard for HIPAA compliance on ePHI at rest.
Most encryption failures happen when key management is deployed separately from existing identity infrastructure. PK Protect deploys key access through Microsoft Entra or Active Directory. Authorized users and applications open encrypted files transparently, the same way they open any other file. Every evaluation includes a scoped POV that validates your specific workflows before production deployment. If a workflow breaks in the POV, you find out before it becomes your IT team's problem.
See what's still readable in your environment, and what closing it actually takes.
You already know where the data is. The question is whether it's protected. Every evaluation is scoped to your specific environment and workflows. If PK Protect can't meet your use cases in the POV, you'll know before you've committed to anything.
Book a Discovery CallNo commitment. Scoped to your environment. You set the success criteria.
