Amendment 13 doesn’t just add bureaucracy. It puts a hard clock on your ability to reconstruct what happened — which means your log infrastructure is now a legal asset, not just an operational one.
What Amendment 13 actually changed
The Israeli Privacy Protection Law has been on the books since 1981. Amendment 13, effective 2025, is the most significant overhaul since the original legislation. Unlike the general updates of 2023–2024 (which clarified definitions and data subject rights), Amendment 13 introduces mandatory data security obligations with specific technical requirements and enforcement mechanisms.
The previous law was largely aspirational: “take reasonable measures to protect data.” Amendment 13 defines what reasonable actually means — and the Privacy Protection Authority (PPA) can now audit your implementation.
| What changed | Before Amendment 13 | After Amendment 13 |
|---|---|---|
| Data security obligations | Vague “reasonable measures” | Specific controls by organization category |
| Breach notification to PPA | No mandatory requirement | Required within 72 hours of discovery |
| Notification to affected individuals | 30 days where required | 30 days, now with documented evidence requirements |
| Security incidents record | Optional internal documentation | Mandatory incident log, must be available on request |
| Database registration threshold | Very broad | Refined with specific categories |
The law defines four categories of organization based on the type and volume of personal data they hold. Category B — which covers most startups and SMBs with more than 100,000 records, or any company holding sensitive categories of data — carries the strictest obligations. If your product touches health data, financial data, or authentication data for more than a handful of users, you’re in Category B.
The 72-hour breach notification requirement
This is where most companies are underprepared. 72 hours sounds like a lot. In practice, between detection, scoping, legal review, and submission, you have almost no slack.
What you need to answer and document within that window:
- When did unauthorized access begin? — You need a timestamp from your logs, not a guess.
- What data was accessed or exfiltrated? — Access logs from your storage layer, API gateway, or application depending on where personal data lives.
- How many individuals are affected? — You need to join event data against user records.
- Was the data encrypted at the time of access? — You need to know which storage paths use which encryption schemes.
- Is the breach contained? — Current status, supported by evidence.
If you’re doing this investigation manually across multiple cloud consoles, a SaaS logging tool, and someone’s local export, you will not make the deadline.
What Amendment 13 requires from your logging infrastructure
Category B data security requirements
Amendment 13 requires Category B organizations to implement:
- Encryption at rest and in transit for all databases containing personal data
- Access control based on need-to-know, with audit logs
- User authentication logs: who logged in, from where, when
- A documented information security program reviewed annually
- An incident log — a record of every security event, whether or not it resulted in a breach
Each of these has direct implications for how you configure and store logs.
Encryption: what the law requires
Amendment 13 specifies AES-256 or equivalent for data at rest, TLS 1.2+ for data in transit. Personal data includes IP addresses, email addresses, user identifiers, behavioral data, and anything linkable to a specific individual.
Your logs contain personal data. CloudTrail-style logs contain user identity ARNs. Identity provider logs contain email addresses. Application logs contain session tokens and user IDs. All of it falls under the obligation.
Key requirements for your log storage layer:
- Logs stored in cloud object storage must use customer-managed encryption keys (not provider-default)
- You must control who can access those keys — an attacker who can read logs and is also a key administrator can cover their tracks
- Encryption applies to both the raw log archive and any indexed/queryable copy in your SIEM
For cloud object storage, the configuration pattern is:
Log bucket policy:
→ Deny any PUT that does not specify encryption: aws:kms
→ Deny any GET from principals not in the authorized-log-readers group
→ Enable versioning (prevents log tampering via overwrite)
→ Enable Object Lock in COMPLIANCE mode, 365-day retention
Access control and audit trails
The law requires you to demonstrate that only authorized personnel accessed personal data. The PPA can request this evidence during an audit or investigation. You need logs of your logs — an audit trail of who queried what.
At minimum:
- Query audit logs from your SIEM: which user ran which query, on which dataset, at what time
- Cloud audit trail: who accessed raw log storage buckets
- Application-level audit logs if analysts can search personal data through a dashboard
A query audit log entry should capture:
{
"timestamp": "2026-05-30T14:22:11Z",
"analyst": "[email protected]",
"query_text": "SELECT ... FROM auth_events WHERE ...",
"tables_accessed": ["auth_events", "okta_logs"],
"rows_returned": 142,
"client_ip": "10.0.1.55"
}
This log must itself be write-protected. An analyst who can delete their own query audit trail can erase evidence of unauthorized access.
For PPA reporting, you need to be able to answer: “Who accessed personal data stored in your logs between date X and date Y?” in under an hour. If that answer requires a manual trawl through five different systems, your access control documentation is insufficient.
Retention: documentation is not optional
Amendment 13 requires a documented retention policy per data category. You cannot keep logs indefinitely “just in case.” You need to justify each retention period.
Practical retention schedule that satisfies both the law and operational needs:
| Log type | Retention | Justification |
|---|---|---|
| Authentication events | 12 months | Supports breach dwell time investigation |
| API and audit trail events | 12 months | Regulatory and forensic requirement |
| Application access logs | 6 months | Operational investigation, not breach forensics |
| Storage access logs | 12 months | Supports data exfiltration investigation |
| Network flow logs | 3 months | High volume, limited forensic value beyond 90 days |
Automate deletion — TTL policies in your SIEM, lifecycle rules in object storage. Manual deletion processes are not compliant: they rely on someone remembering to run a script.
The retention policy must be a written document, reviewed annually, signed off by a responsible person. “We delete logs when the bucket gets full” is not a retention policy.
The mandatory incident log
This is the part most companies overlook. Amendment 13 requires organizations to maintain an ongoing incident log — a record of every security event that may have affected personal data, regardless of whether it resulted in a confirmed breach.
This is not a list of confirmed breaches. It includes events you investigated and closed as false positives. The PPA uses this log to assess whether your detection and response processes are functioning.
Each incident log entry should capture:
{
"incident_id": "INC-2026-0042",
"detected_at": "2026-05-14T08:31:00Z",
"severity": "high",
"type": "unauthorized_access_suspected",
"personal_data_involved": true,
"affected_records_estimate": 0,
"ppa_notification_required": false,
"ppa_notification_sent_at": null,
"containment_at": "2026-05-14T09:15:00Z",
"resolution_at": "2026-05-14T11:02:00Z",
"analyst": "[email protected]",
"outcome": "False positive — anomalous login from VPN exit node, confirmed by user"
}
Every alert that touches personal data generates a record, including those that resolve as false positives. When the PPA asks for your incident log, you export this dataset.
Handling data subject rights against your logs
The right of erasure is the hardest part operationally. Under Amendment 13, a data subject can request deletion of their personal data. If their email address appears in your security logs, you technically need to respond — but deleting log entries conflicts with forensic integrity requirements and potentially with other regulations.
The approach most Israeli legal teams accept: pseudonymize PII at ingest time rather than storing it raw.
Hash email addresses and user identifiers before they reach your SIEM. Store the mapping in a separate, access-restricted system with its own retention policy. When a deletion request comes in, delete the mapping row. The hash in the event log becomes unlinkable to the individual.
The pseudonymization pipeline:
Log event arrives at ingest pipeline
→ Extract PII fields (email, user_id, full_name)
→ Hash each field with HMAC-SHA256 (use a secret key, not a bare hash)
→ Store hash in the event log
→ Store { hash → plaintext } in a separate, restricted mapping table
→ Original PII never written to the SIEM
On erasure request:
→ Delete the mapping row for the data subject
→ Hash in event log now has no linked plaintext → obligation satisfied
→ Security logs remain forensically intact
The mapping table itself must have its own encryption, access controls, and TTL. It is personal data — treat it accordingly.
What to prepare for a PPA audit
If the PPA investigates a reported breach or audits your organization, they will ask for:
- Record of Processing Activities (ROPA) — what personal data you collect, stored where, processed for what purpose, retained for how long
- Technical security measures evidence — encryption configuration, access control policies, network segmentation documentation
- Incident log — the full dataset for the period in question
- Breach timeline — when the breach started, when you detected it, what you did, when you notified
Your SIEM should be able to generate the breach timeline automatically from stored events. A parameterized investigation query that takes a time range and a set of indicators (IP address, user account, resource identifier) and returns a time-ordered event sequence — your analysts shouldn’t be reconstructing this by hand during a crisis.
Reconstruction query (pseudo-code):
QUERY events
WHERE source_ip = <indicator_ip>
AND timestamp BETWEEN <incident_start> AND <incident_end>
SELECT timestamp, event_type, actor_hash, resource_id, result
ORDER BY timestamp ASC
Running that query and exporting the result in under five minutes is the difference between a controlled PPA conversation and a weeks-long investigation.
Final thought
Amendment 13 is not primarily a logging regulation. But the 72-hour PPA notification window, the mandatory incident log, the access audit requirements, and the data subject rights framework — none of these are satisfiable without centralized, encrypted, queryable logs with proper retention controls and audit trails.
If you haven’t mapped your logging infrastructure against these requirements, that review is overdue. If you want to assess your current posture, contact us.