Data Protection

Your data leaves SAP protected. Field by field. Before it moves.

Not every field needs the same protection. Not every field needs protection at all. DataXover applies the right treatment to each field independently — configured in the extraction profile, enforced inside SAP at extraction time, before a single value leaves your system.

The destination receives data already in its intended state. There is no pipeline to secure after the fact. There is no post-landing transformation to trust.

The ISV Story

The ISV never sees your data. Their application works anyway.

Every field that matters — customer numbers, vendor IDs, account references — is protected inside your SAP system before it leaves. The ISV receives tokens they can join on and encrypted values they cannot read. Their analytics work. Their application works. Your data never exists in their environment in plaintext.

That's not a privacy feature. That's the thing that makes B2B data sharing deals actually happen.

Six Modes

The right protection for each field. Nothing more, nothing less.

Pseudo

HMAC Token

The value is replaced with a deterministic, non-reversible token. The same input always produces the same token — enabling joins and correlations across datasets without exposing the underlying value. For identifier fields that need to correlate but not display. Customer numbers used as join keys. Vendor IDs. Account references.

Encrypt

AES-256

The value is encrypted and reversible through an authorized API call. For specific identifier and text fields that need to be protected in transit and at rest but may need to be resolved by authorized parties under controlled conditions. Not appropriate for numeric fields used in calculations — encrypting values that need to support aggregation or arithmetic breaks downstream analytics.

Both

Dual Output

A single source field produces two output columns simultaneously. The _PS column contains an HMAC token — deterministic, non-reversible, for joining. The _IV column contains an AES-256 encrypted value — reversible through authorized API call, for recovery. One field. Two purposes. The ISV's application joins on _PS and never sees the raw value. Your authorized users recover the original through _IV when business requirements demand it.

Redact

Value Removed

The value is replaced entirely. The column exists in the output for structural completeness. The content is gone. For fields that should never leave your SAP system under any circumstance.

Mask

Partial Visibility

Enough of the value is retained to be recognizable — trailing digits of an account number, a partial identifier — without full disclosure. For fields where context matters but full exposure doesn't.

None

Passthrough

The raw value moves untouched. Currency codes, units of measure, document types, numeric values used in downstream calculations — fields with no sensitivity or fields that need to remain analytically intact. The default for non-sensitive data.

Deep Dive: Both Mode

The mode that makes B2B data sharing deals happen.

The objection that kills most B2B data sharing conversations isn't technical. It's this:

"We can't let them see our customer numbers."

It's a reasonable objection. Customer numbers, vendor IDs, account references — these are sensitive identifiers that map to real business relationships. Sharing them with an outside party creates exposure that legal, compliance, and the CISO won't approve.

But without those identifiers, the ISV's application can't join across datasets. The analytics don't work. The deal dies.

Both mode eliminates the tradeoff.

Take a customer number field on SAP object KNA1. Configured with Both mode, it produces two columns at extraction time inside your SAP system:

For Joining

_PS — HMAC Token

Computed from the source value using your customer-specific key. Deterministic — the same customer number always produces the same token, every time, across every extracted object. Non-reversible — the token cannot be worked backwards to the original value. The ISV receives this token everywhere the customer number appears — in VBAK, in VBAP, in KNA1. The tokens match across all three objects. Every join works. Every correlation holds.

For Authorized Recovery

_IV — AES-256 Encrypted

The source value encrypted with AES-256 using your customer-specific Data Encryption Key. Reversible — when an authorized user in your organization needs to see the real value for display, audit, or resolution, it can be decrypted through an authorized API call. This is your recovery path. Not the ISV's. The decryption capability belongs to you.

The ISV's application operates entirely on _PS tokens. It never requests, receives, or processes your actual customer numbers. Their analytics work. Their joins work. Their application works.

Your end users, viewing results through the ISV's application, see real values — because your authorized system decrypts _IV for display. They see the actual customer name. The actual vendor. The actual account reference.

The ISV built the application on protected data. Your users see real data. Your actual values never existed in the ISV's environment in plaintext.

That's not a privacy feature bolted on after the fact. That's the architecture.

Regulatory Mapping

One field configuration. Multiple frameworks addressed.

Privacy regulations share a common requirement: sensitive personal data should not be accessible to parties who don't need it, and should not exist in plaintext where it can be exposed.

Requirement	Relevant Mode	How
GDPR — pseudonymization	Pseudo / Both	HMAC token is deterministic and non-reversible. Original value cannot be derived from it.
GDPR — data minimization	None / Redact	Only selected fields extracted. Fields that shouldn't leave SAP excluded or redacted entirely.
CCPA — unauthorized access	Pseudo / Both / Encrypt	Protected identifiers cannot be read by unauthorized parties. Recovery requires authorized API call.
HIPAA — de-identification	Redact / Pseudo / Encrypt	Protected health information fields removed, tokenized, or encrypted at extraction time.
Internal governance	Any mode	Applied per field, per profile. Governance enforced at source before data reaches analytics layer.

DataXover is not a compliance product and does not provide legal advice. The regulatory mappings above describe technical capabilities relevant to common compliance requirements. Your compliance and legal teams should determine applicability to your specific situation.

Key Management

Keys managed by industry-standard infrastructure. Never stored in SAP.

Encryption keys and HMAC keys are issued and managed through AWS Key Management Service (KMS) — industry-standard key management infrastructure with FIPS 140-2 validated hardware security modules. DataXover does not implement its own cryptographic key storage.

Keys are retrieved by the SAP system via outbound API call at extraction time. Used in memory during the extraction process. Never written to SAP configuration tables, database tables, or the file system.

The significance: anyone with SE16 access to your SAP system cannot read your encryption keys. The keys are not there. They were never persisted to the system that holds your data.

Key rotation: AES-256 Data Encryption Key rotation is supported — previously extracted encrypted values can be re-encrypted under the new key. HMAC key rotation is a significant operation: because pseudonymization is deterministic, rotating the HMAC key invalidates referential consistency between historical and new extractions. A full rebuild of affected datasets is required. Plan accordingly.

Protection at Source

The pipeline window that doesn't exist.

Most data protection approaches work at the wrong layer. Encrypt in transit. Mask on landing. Apply governance rules after the data reaches the analytics platform.

These approaches have something in common: between the moment data leaves the source system and the moment protection is applied, raw sensitive values exist somewhere outside the source. In a file. In a message queue. In a staging table. That window is where exposure happens.

DataXover closes that window entirely.

Protection is applied inside your SAP system, in memory, during the ABAP extraction process, before the output file is written. The file staged on the application server file system already contains protected values. The file that uploads to cloud object storage contains protected values. The record that lands in your destination database contains protected values.

Raw sensitive values exist in one place: inside your SAP system, where they have always been, under your existing security and authorization controls.

There is no pipeline window. There is no staging layer to secure. There is no transformation to trust after the fact.

The destination receives exactly what was intended — and nothing that wasn't.

Data sharing without compromise.

Field-level protection is one of several capabilities that make DataXover the only native SAP extraction platform.

Request Consideration Explore OneScope