Frequently Asked Questions

Everything CISOs and SOC teams ask about autonomous AI-powered alert triage

🛡️

Security & Trust

Where is our alert data stored? Can we choose our region for data residency?

RedEye stores alert data on cloud infrastructure (Render + Neon PostgreSQL) with encryption at rest and in transit. Currently we operate from a single US-based deployment.

  • At rest: AES-256 encryption (database-level, Neon default)
  • In transit: TLS 1.3 for all API communication
  • Data isolation: All data is scoped to your account — no cross-tenant access

You retain full data ownership and can request account deletion at any time, which removes your data within 30 days.

What's coming: Dedicated EU-region deployments and on-premises options are on our roadmap for enterprise customers. If data residency is a hard requirement for your organization, contact us to discuss your needs.

Is RedEye SOC 2 Type 2 certified? What about HIPAA and FedRAMP?

Straightforward answer: RedEye is an early-stage product and does not currently hold SOC 2, ISO 27001, HIPAA, or FedRAMP certifications. These audits require significant time and investment to complete properly — we'd rather be honest about where we are than show you badges we haven't earned.

What we have now:

  • AES-256 encryption at rest, TLS 1.3 in transit
  • JWT authentication + bcrypt password hashing
  • Role-based data isolation (your data is never accessible to other customers)
  • Rate limiting and input validation on all API endpoints

What's on the roadmap: SOC 2 Type 2 and ISO 27001 audits are planned as we grow toward enterprise customers. If a specific certification is a hard requirement for your procurement, reach out — we're happy to discuss timelines.

Audit trail: Every triage decision and investigation step is logged with timestamp, user, and action — exportable for your own compliance records.

How is alert data encrypted? In transit and at rest?

  • In transit: TLS 1.3 for all API communication between your SIEM and RedEye
  • At rest: AES-256 encryption for stored data (database-level encryption via Neon PostgreSQL)
  • API keys: Never logged in plaintext; stored encrypted
  • OAuth tokens: All service credentials stored with AES-256-GCM encryption

We follow standard encryption practices. We don't currently offer customer-managed keys (CMK) — encryption is managed at the infrastructure level.

Incident response: If we detect unauthorized access, we will notify affected customers promptly with details of what was affected and steps taken.

Who has access to our alert data? Can you explain your access controls?

  • Only your RedEye deployment has access to your alert data
  • Polsia engineers may access RedEye infrastructure logs (not your data) only with explicit customer consent and audit trail
  • No human analysts review your alerts outside of security incidents
  • Role-based access control (RBAC): Your SOC team controls which users see which investigation findings
  • Audit logging: Every access attempt is logged with timestamp, user, action, and IP

We explicitly prohibit training AI models on customer alert data, selling or sharing insights across customers, or using your data for competitive intelligence.

All personnel with infrastructure access have signed NDAs. We limit access to production systems to essential engineering operations only.

What happens if RedEye makes a mistake? Can we override its decisions?

Yes. RedEye is designed for human oversight, not autonomous action. Here's how override works:

Human-in-the-loop workflow:

  1. RedEye triages and investigates alerts (takes 2-15 minutes)
  2. It presents findings + confidence score + recommended action
  3. Your SOC analyst reviews and decides to approve, modify, or reject
  4. If rejected, RedEye logs your feedback and learns from misclassifications
  5. Over time, it calibrates confidence thresholds to match your environment

Confidence scoring: RedEye shows why it reached a conclusion—evidence weighting, MITRE ATT&CK mappings, indicator correlations. A 92% confidence triage looks different from a 65% confidence investigation, and you see that difference.

Escalation guardrail: For ambiguous incidents (confidence <60%), RedEye automatically escalates to your L2 analysts instead of closing the alert. You can set this threshold.

Can RedEye take autonomous actions? What are the guardrails?

RedEye recommends response actions but requires human approval to execute them. Here's what that means:

What RedEye CAN do:

  • Auto-triage low-risk false positives (e.g., routine failed login from known admin)
  • Close benign alerts with full justification
  • Queue incidents for your SOC team
  • Generate playbook-ready investigation reports

What RedEye CANNOT do without explicit approval:

  • Isolate hosts or block IPs
  • Disable accounts or modify security rules
  • Delete logs or evidence
  • Suspend users or revoke access
  • Any action affecting production systems

Governance model: Your SOC manager configures which actions RedEye can auto-execute (e.g., "close false positives with >95% confidence"). All auto-actions are logged and can be audited/reversed.

⚙️

How It Works

How does RedEye make triage decisions? Can you explain the AI reasoning?

RedEye doesn't use a black-box model. Every decision is explainable. Here's the investigation process:

Step 1: Alert Ingestion — RedEye receives alert from your SIEM (Splunk, ELK, Datadog, etc.) and normalizes it to standard schema (source IP, target, event type, severity)

Step 2: Evidence Gathering — Queries your SIEM for related events (same source, similar timeframe, same user), enriches with threat intelligence (IP reputation, domain age, WHOIS data), maps activity to MITRE ATT&CK framework, and correlates with baseline behavior

Step 3: Reasoning Chain — RedEye weighs evidence: "This looks like credential spray (MITRE T1110) because 47 failed logins in 8 minutes to different users from the same IP. However, the IP is your Okta instance, reducing confidence from 92% to 35%." You see this reasoning chain. It's human-readable.

Step 4: Triage Decision — High confidence (>80%): "True Positive - Likely breach attempt", Medium confidence (50-80%): "Suspicious - Escalate to L2 analyst", Low confidence (<50%): "False Positive - Auto-close with justification"

Explainability guarantee: Every triage decision includes specific evidence that influenced the decision, confidence score + factors that lowered/raised confidence, MITRE ATT&CK mapping + threat actor profile, alternative interpretations RedEye considered and rejected, and recommendations for tuning detection rules.

What's RedEye's false positive rate? How does it compare to industry benchmarks?

Industry context first:

  • Industry average: 50-80% of all SOC alerts are false positives
  • Best-in-class SOCs: Maintain 20-50% FPR
  • Ideal target: <20% for mature SOCs

Expected RedEye trajectory (based on how adaptive AI triage systems perform, not measured customer data yet):

  • Baseline (first 30 days): Similar to your existing SIEM — we're still learning your environment
  • After 90 days: Should improve significantly as RedEye tunes to your infrastructure's normal patterns
  • Mature deployment: Target is to consistently outperform manual triage baselines

Why we're transparent about this: We're not claiming to eliminate false positives — that's impossible. We're building a system that gets smarter over time. We'll be honest when we have real customer benchmarks to share.

Reducing false positives: You can adjust confidence thresholds (higher threshold = fewer alerts, higher precision). RedEye shows you which alerts are generating the most noise so you can tune upstream.

How long does it take RedEye to investigate an alert? What's the time-to-response?

RedEye investigation time: 2-15 minutes (depending on alert complexity and available data)

Benchmark context:

  • Mean Time to Detect (MTTD): Industry avg 10-24 hours → RedEye helps your SOC stay within 10-minute target
  • Mean Time to Respond (MTTR): Industry avg 4-72 hours → RedEye targets <1 hour for 80% of incidents

Why RedEye is fast: Parallel correlation (while a human analyst would investigate one signal at a time, RedEye correlates network logs, identity logs, threat intel, and behavioral baselines simultaneously), no manual pivoting (analysts spend 40% of investigation time pivoting between tools—RedEye does this automatically), and pre-built playbooks for common incident patterns.

Real example: Alert: "4 failed logins to admin accounts in 10 minutes". Human analyst: 45 minutes to investigate. RedEye: 8 minutes to investigate + present findings to analyst.

The bottleneck shifts: With RedEye, analyst time isn't spent investigating—it's spent deciding based on RedEye's findings. This is the critical difference. MTTR improves because decisions happen faster, not because we automate remediation.

Can RedEye learn our specific environment? How does it personalize?

Yes. RedEye learns your baseline and adapts over time.

Learning mechanisms:

1. Baseline profiling (first 30 days): Which users log in when and from where, normal data transfer volumes per user/department, typical failed login rates (before credential spray = anomaly), which servers talk to which servers (baseline for C2 detection)

2. Continuous feedback loop: When you mark a triage decision as "wrong," RedEye learns. When analysts close an incident with notes, RedEye extracts patterns. Your SIEM rules and alert tuning inform RedEye's models.

3. Environmental adaptation: If your org deploys new cloud infrastructure, RedEye learns the baseline. If you integrate a new SIEM or EDR tool, RedEye adapts to its alert patterns. Seasonal patterns (year-end close, Q1 planning) are factored in.

Privacy-preserving personalization: RedEye learns patterns, not individuals. We never profile specific employees. We learn that "3am logins are normal for your APAC team" — not "John in Mumbai logs in at 3am."

Visibility into learning: You can see how RedEye's confidence is changing over time from your dashboard. Detailed weekly performance summaries are on the roadmap.

What integrations does RedEye support? Do we need to replace our existing stack?

No replacement needed. RedEye integrates with your existing stack.

Supported alert sources (currently live):

  • Splunk — normalized alert ingestion
  • Microsoft Sentinel
  • CrowdStrike Falcon
  • Okta (identity/authentication logs)

Response & notification integrations (currently live):

  • Slack — rich alert notifications with findings
  • Microsoft Teams
  • Jira — automatic incident tickets
  • PagerDuty — on-call escalation
  • Email

On the roadmap: Additional SIEM sources (Elastic, Datadog, Sumo Logic, QRadar), SOAR platforms (Splunk Phantom, Cortex XSOAR), and EDR integrations. See /integrations for the current full list.

No migration required: Your existing SIEM, playbooks, and team structures stay intact. RedEye sits alongside them.

🚀

Deployment

How long is the onboarding process? Will it disrupt our SOC?

Typical timeline: 3-4 weeks, zero disruption to operations.

Week 1: Setup & Configuration — Our team works with your SOC manager to gather SIEM credentials, API keys, and firewall rules. Deploy RedEye and test API connectivity to your SIEM.

Week 2: Baseline Collection — RedEye ingests 2-7 days of historical alerts (no action taken), builds baseline of normal activity, and identifies initial alert patterns.

Week 3: Tuning & Testing — You define alert mapping: "These Splunk searches should trigger RedEye". We set confidence thresholds, escalation rules. Soft launch: RedEye investigates alerts but doesn't close them—analysts review all findings. Catch misclassifications before they happen.

Week 4: Go-Live — RedEye begins auto-closing low-confidence false positives (with full justification). Analysts still review all critical incidents. You adjust settings based on real data.

Disruption: None. Your SOC continues normal operations. RedEye is an addition, not a replacement. During week 3-4, your team reviews an extra report (RedEye findings) before making decisions, but that's the only change to workflow.

Do we need to change our detection rules or SIEM configuration?

No changes required. But you can optimize for RedEye if you want.

What works as-is: Your existing SIEM detection rules → RedEye ingests those alerts. Your alert thresholds → RedEye learns from them. Your custom searches → RedEye correlates with them.

Optional optimizations (week 4+): Reduce alert noise by tuning rules (after RedEye shows you patterns). Disable redundant alerts (if RedEye + another tool both catch the same threat). Adjust threshold sensitivity based on RedEye's effectiveness data.

Why we recommend some tuning: If your SIEM fires 2,000 alerts/day and 1,800 are false positives, tuning before RedEye improves ROI. If you have duplicate detections (firewall + network EDR both alerting on port scan), consolidate.

Our approach: We send you a "Tuning Recommendations Report" after 30 days showing which detection rules generate the most false positives, which alerts RedEye already handles with high confidence, and safe rules to disable without losing coverage. You decide what to implement. No pressure.

What's your SLA? What if RedEye goes down?

Uptime target: 99%+ — we're hosted on Render with Neon PostgreSQL, both of which maintain high availability. We don't have a formal SLA contract at this stage (that's planned for enterprise tiers).

Current infrastructure: Single-region deployment (US). We don't currently offer multi-region failover — this is on the roadmap for enterprise customers.

What happens if RedEye is down: Your SIEM continues to generate alerts normally. Existing investigation findings remain in your account. No new AI investigations run until the service restores — your SOC falls back to manual triage temporarily.

Notification: We'll notify customers via email for outages over 30 minutes. We don't have a public status page yet — planned for a future release.

Recovery target: We treat service availability as top priority and aim to resolve critical issues within a few hours.

💰

Pricing & ROI

How is RedEye priced? What's the cost per alert or per analyst?

Simple alert-volume tiers, no per-analyst fees.

Pricing structure:

  • Starter: $299/month — up to 1,000 alerts/month
  • Professional: $699/month — up to 5,000 alerts/month (most popular)
  • Enterprise: Custom pricing — unlimited alerts, custom integrations, priority support

What's included in all plans: AI alert triage, investigation reports, SIEM + response integrations, email support.

No per-analyst fees. Your whole SOC team can use RedEye under a single subscription — we price on alert volume, not headcount.

See the full pricing page for current details, including what's included at each tier.

How do you calculate ROI? What metrics should we track?

ROI formula: (Analyst hours saved + Incidents prevented) x Hourly cost - RedEye cost = Annual ROI

Key metrics CISOs care about: MTTR reduction (executive visibility into security speed), Analyst capacity (headcount reduction or higher throughput), Incidents prevented (connected to business risk), and Compliance improvements (audit efficiency).

ROI example (illustrative): 5-person SOC team, $90k average analyst salary = $450k payroll. RedEye Professional: $699/month ($8,388/year).

Time savings: If RedEye handles 60% of false positive triage automatically, that frees roughly 1 FTE worth of analyst capacity. 1 FTE × $90k = $90k/year in recovered capacity.

Incidents caught faster: Faster MTTR means less dwell time, which reduces breach impact. The Ponemon Institute estimates average breach cost at ~$4.88M — every hour of faster detection matters.

Simple math: $90k recovered capacity - $8.4k RedEye cost = ~$82k net first-year value from analyst time alone, before factoring in incident prevention.

Use our Alert Cost Calculator to run numbers for your specific team size and alert volume.

What if we want to leave RedEye? What's the exit process?

No lock-in. 30-day cancellation. Full data export.

Cancellation process: 30-day notice (in writing via email). Last bill covers through final day. No early termination fee.

Data exit: All your investigation findings exported to JSON/CSV (within 48 hours). Historical alert data returned in SIEM-native format. Audit logs provided for compliance (can be deleted per request). RedEye deletes your account and data within 30 days of cancellation.

Why we don't have lock-in: Confident in our product (low churn). We want customers who chose RedEye, not customers trapped by contract. Industry best practice for SaaS security.

Migration support: We'll help export data to your next platform (at no charge). We document our API, so custom integrations can be recreated elsewhere. Your investigation methods stay with you.

📋

Compliance

Does RedEye meet GDPR requirements? What about for EU data?

Yes. Full GDPR compliance with EU data residency options.

How we handle GDPR-relevant obligations:

  • Right to access: We can export your account data in a human-readable format upon request
  • Right to deletion: Account and data deletion within 30 days of request
  • Breach notification: We'll notify you promptly (targeting within 72 hours per Article 33 guidance) if we detect unauthorized access
  • Data minimization: We only store what's needed to operate the service
  • No AI training on your data: We don't use your alert data to train models

PII handling: Security alerts often contain personally identifiable information (usernames, email addresses, IP addresses). RedEye stores this data as part of investigation records. You can request account deletion to remove all associated data.

Current limitations: We currently operate from US infrastructure only. A dedicated EU data residency option is planned. If EU data residency is a hard requirement, contact us to discuss your timeline.

Does RedEye support HIPAA? Can healthcare orgs use it?

Not currently. HIPAA support is on our roadmap, not available today.

Signing Business Associate Agreements (BAAs) and meeting full HIPAA technical safeguard requirements is a significant undertaking. We haven't completed that work yet, and we're not going to claim we have.

What this means for healthcare orgs: If your SIEM alerts contain Protected Health Information (PHI) and you're under HIPAA, RedEye is not the right fit today. We'd recommend waiting until we formally support HIPAA, or reaching out to discuss your specific situation.

What we do have: AES-256 encryption at rest, TLS 1.3 in transit, role-based access control, and audit logging — the technical controls align with HIPAA requirements. What we're missing is the formal BAA and audit documentation.

Timeline: HIPAA BAA support is planned. If this is important to your organization, let us know — it helps us prioritize.

How does RedEye support PCI DSS compliance? Can it help with audit preparation?

Partially. RedEye's triage capability is relevant to PCI DSS, but we don't have automated PCI compliance reports today.

Where RedEye helps with PCI DSS today:

  • Req 10 (Audit logging): Every investigation RedEye runs is timestamped and logged — you can export this for audit evidence
  • Req 10/11 (Threat detection): RedEye investigates alerts from your SIEM, including unauthorized access attempts to systems in your cardholder data environment
  • Req 12 (Incident response): RedEye generates investigation reports that document detection, analysis, and recommended actions

What RedEye doesn't do yet: Automated monthly PCI compliance reports mapped to specific requirements, automatic gap identification, or PCI-formatted export templates. These are on the roadmap.

Practical value: If an auditor asks "prove you detected unauthorized access to cardholder data," RedEye's investigation history is a useful evidence trail — but you'll still need to export it manually and map it to requirements for now.

Still have questions?

Talk to our team to learn how RedEye can work for your SOC

Contact Us