Electronically Signed By:
Rafael Jara
Incident Notification Procedure (IR.2)
Organization: Fintable, Inc.
Owner: Security & Compliance
Review Cadence: Annual or upon material change
Approved By: Rafael Jara
Approval Date: 2025 August 15
1) Purpose & Scope:
This procedure outlines the process for Fintable to notify Akoya and affected
customers about information security incidents that compromise Personally
Identifiable Information (PII) or disrupt the availability and integrity of
Fintable services. It applies to incidents occurring in production and corporate
environments, as well as those originating from vendors or processors that
impact Fintable data or services.
2) Definitions:
- Security Incident: An event that compromises the confidentiality, integrity,
or availability of systems or data, including unauthorized access, data
exfiltration, malware or ransomware, credential compromise, or significant
service disruption.
- Breach (PII Incident): Unauthorized acquisition or disclosure of PII or
Customer Data, or a reasonable belief thereof.
- Awareness: The time Fintable has reason to believe an incident may have
occurred, such as through an alert or report.
- Confirmation: The time Fintable verifies an incident has occurred and
determines the affected systems or data with reasonable certainty.
3) Roles & Responsibilities:
- Incident Commander (IC): Leads the response efforts, determines the severity
of the incident, and triggers notifications.
- Security Lead: Coordinates the triage and forensics processes, documents the
timeline and evidence.
- Legal/Privacy: Advises on regulatory obligations and approves the content of
the notification.
- Communications Lead: Delivers notifications to Akoya, customers, partners, and
internal stakeholders.
- Customer Support Lead: Manages inbound inquiries and provides customer
guidance.
- Vendor Manager: Collaborates with affected third parties and ensures timely
notifications.
4) Severity & Notification Triggers
Notifications are mandatory for incidents that meet any of the following
criteria:
- Confirmed or probable compromise of Personal Identifiable Information (PII) or
Customer Data.
- Significant degradation or outage of Fintable services that impact customers.
- Legal or regulatory reporting thresholds are exceeded (e.g., applicable
privacy laws).
- Contractual obligations with Akoya or other partners necessitate notification.
5) Notification Timeframes (SLAs)
Fintable will notify promptly, adhering to the following maximum targets unless
a stricter contractual or regulatory requirement applies:
Audience | Trigger | Initial Notification SLA
---------------------------|-----------------------------------|---------------------------
Akoya | Confirmed or likely incident | Within 72 hours of
| affecting PII or Akoya-integrated | confirmation (or earlier
| services | advisory within 12 hours
| | if high likelihood)
Customers | Confirmed PII impact or material | Within 72 hours of
| service impact | confirmation (earlier if
| | mandated by law/contract)
Regulators (if applicable) | Legal threshold met | As required by law (e.g.,
| (jurisdiction-specific) | ≤72 hours under certain
| | regimes)
Status updates will be provided at least every 24 hours (or as mutually agreed
upon) until containment is achieved. A post-incident summary and Root Cause
Analysis (RCA) will be provided within 10 business days of containment.
6) Notification Channels & Contacts
- Akoya: Notify via the designated Akoya security contact or channel on file.
Maintain a primary and secondary contact list internally.
- Customers: Email the affected customers’ registered account contacts and/or
display an in-app banner. Update the status page for service-impacting events.
- Internal: Use executive and engineering channels, the incident room, and
ticket reference for internal communication.
- Law Enforcement & Regulators: Officers managing legal and privacy matters will
coordinate with them as required.
7) Notification Content Requirements
7.1) Incident report requires date, time, description, scope, impact, containment,
remediation, customer actions, contact info, and legal disclosures.
8) Process Steps
8.1) Detect and Triage: The Incident Commander (IC) assigns the severity of the
incident, and the Security Lead initiates the investigation. Evidence
preservation and logging begin immediately.
8.2) Decide Notification: If the incident triggers any of the conditions outlined
in §4, the Communications Lead drafts notifications with the approval of Legal
and Privacy.
8.3) Send Initial Notice: Deliver the initial notice to Akoya and customers within
the specified SLAs in §5. If applicable, open a status page incident.
8.4) Ongoing Updates: Provide updates at least every 24 hours or whenever material
changes occur.
8.5) Post-Incident Report: Deliver a summary of the incident and the corrective
actions taken to Akoya and customers (as appropriate) within 10 business days.
8.6) Lessons Learned: Conduct a post-mortem within 10 business days and track the
action items to ensure closure.
9) Evidence Preservation and Forensics
9.1) Preserve relevant logs, disk images/snapshots, and configuration states,
maintaining a clear chain of custody.
9.2) Restrict access to only those who need it and involve legal counsel for
privilege claims when necessary.
9.3) Retain incident records according to the retention policy, which typically
requires a minimum of one year, unless the law mandates a longer retention
period.
10) Third-Party and Vendor Incidents
10.1) Vendors processing Fintable data must promptly notify Fintable of any
incidents that may impact Fintable.
10.2) Fintable will transmit the applicable notifications to Akoya and customers as
per this procedure.
10.3) Vendor SLAs for notification should be clearly defined in the contract and
monitored.
11) Training and Testing
11.1) Conduct regular training sessions to ensure that all relevant personnel are
familiar with the incident response procedures.
11.2) Perform regular testing to identify and address any weaknesses or
vulnerabilities in the incident response process.
11.3) Annual incident response training is provided for IC, Security, Communications,
Customer Support, and Legal/Privacy roles.
11.4) Tabletop exercises are conducted at least annually, including a PII-impact
scenario and an Akoya-integrated service outage scenario.
12) Review & Maintenance
12.1) This procedure is reviewed annually and after any significant incident. Contact
rosters and templates are updated quarterly or whenever there are personnel
changes.
Appendix A — Notification Templates
A.1) Akoya Initial Notice (Email/Portal)
Subject: [Fintable] Security Incident Advisory — [Short Description] —
[YYYY-MM-DD]
Body (brief): Provide a concise summary of the event, the time it was detected
or confirmed, the potential impact on Akoya-related services or PII categories,
the containment measures taken, the next update time, and the contact person.
A.2) Customer Initial Notice (Email)
Subject: Important Security Notice from Fintable — [Short Description]
Body (brief): Explain what transpired, the information that may be involved, the
actions being taken, what customers can do, contact details, and the next update
timing.
A.3) Status Page Entry
Title: Service Incident — [System/Region]
Content: Outline the scope of the incident, its impact, the time it began, the
mitigation steps being taken, and the estimated time for the next update.
Approved By:
Rafael Jara
Vice President
Electronically Signed By:
Rafael Jara