Salesforce + cybersecurity: the cost of isolating these teams

Insight · Cybersecurity × CRM

Salesforce and cybersecurity teams should not be strangers — the cost of isolating them.

By Inithex Practice · 7 min read · May 2026

In most enterprises we walk into, Salesforce and cybersecurity belong to different leaders, different vendors and different budget lines. That separation made sense when CRM was a sales tool and security was a perimeter firewall. Neither is true anymore.

Why the wall exists in the first place

The historical reasoning is straightforward. CRM lived under Sales or Customer Success. Security lived under IT or, increasingly, a dedicated CISO. Each grew its own vendor ecosystem, its own consultants, its own KPIs. CRM optimized for revenue velocity; security optimized for risk reduction. The two rarely needed to coordinate because the data flowing through CRM was, frankly, less interesting to attackers than financial systems or core banking.

That changed when CRMs became the system of record for everything — customer identity, financial relationships, sensitive product data, employee performance reviews, partner contracts. Today, a fully populated Salesforce org is among the highest-value targets in any enterprise. Yet the security model around it is often inherited from the era when CRM was sales notes.

Where the bleed shows up

Three patterns repeat across our engagements:

Permissions sprawl. Without security review, profiles, permission sets and sharing rules accumulate. We have audited orgs with 400+ permission sets, most created during one-off project requests. Each is a potential lateral-movement vector. Each also slows down legitimate admins.

Integration blind spots. Custom integrations to ERP, data warehouses or third-party SaaS are typically built by Salesforce delivery teams without security review. We routinely find hardcoded credentials, over-privileged service accounts and unmonitored data egress.

Conversely, security teams that do not understand Salesforce assume the worst, blocking legitimate integrations and adding latency to revenue-critical flows. Both teams build workarounds for the other team. Nobody wins.

What an integrated model looks like

The first move is structural, not technical: a joint architecture review board where the Salesforce architect and the security architect sign off on every integration, permission model change and major release. This board does not need to slow delivery; the right operating cadence is 90 minutes weekly.

The second move is observability. Salesforce Shield event monitoring (or its equivalent in your edition) feeds the SOC SIEM, alongside infrastructure and endpoint logs. SOC playbooks gain Salesforce-specific scenarios: privileged user impersonation, mass exports, API anomaly detection.

The third move is shared incident response. The runbook for a credential compromise involves both teams from minute zero — not as a handoff but as a joint operation. The Salesforce admin knows what data was exposed; the security analyst knows how the breach happened. Together, they contain it.

What it costs to ignore

In one engagement, a regional bank had three Salesforce orgs. Their security team did not know one of them existed — it had been spun up by a marketing team using a corporate credit card. That org contained 80,000 customer records and was integrated with an unmaintained scraper that ran nightly. Detection happened during our discovery phase, not through the SOC.

The cleanup cost more than a year of joint architecture reviews would have cost. The bank now runs a joint review board. They have not found another rogue org since.

Want a joint review of your Salesforce + security posture?

30 minutes with one of our architects and one of our Inithex security leads. We will tell you the three things we would tackle in your first 90 days.

Book a joint review →

Open banking in LATAM: a practical readiness guide

Insight · Financial Services

Open banking in LATAM: a practical readiness guide for incumbents.

By Inithex Practice · 9 min read · May 2026

The headlines on open banking in LATAM focus on dates: Mexico’s LRITF, Brasil’s phased Open Finance, Chile’s SBIF framework. The interesting story is what happens inside an incumbent bank that needs to comply — not because the API specs are hard, but because the institution was never designed to expose its own data on someone else’s schedule.

The four readiness dimensions that actually matter

Technical readiness is necessary but not sufficient. We assess clients across four dimensions: API surface (can your core systems even expose the required endpoints with the required SLAs?), identity and consent (do you have a working customer identity layer that supports granular, revocable consent?), data governance (do you know which fields are in scope, which are derived, which are protected by other regulations?), and operating model (when a fintech partner has an outage, who in your bank handles it?).

Most incumbents have a plan for #1 and #2. Few have one for #3 and #4. The institutions that struggled in the early Brasilian phases were not the ones with weaker APIs — they were the ones whose operations teams had no playbook for partner-driven failures.

Why Salesforce + MuleSoft is not the same as open banking

We say this gently because we deliver both: having Salesforce Financial Services Cloud and MuleSoft does not make you open-banking-ready. It makes you well-positioned to become ready, but the open banking journey adds three layers that those platforms alone do not provide.

First, the consent management layer. Open finance regimes require customer-driven, time-bound, revocable consent at the data-element level. Out-of-the-box CRM consent is not granular enough.

Second, the certified API gateway with regulator-recognized authentication (FAPI, OIDC FAPI-CIBA, mTLS depending on jurisdiction). MuleSoft can host this but the configuration must match the local regulator’s technical spec exactly.

Third, the auditable event log. Every consent grant, every API call, every data element transmitted must be reconstructable years later. This is a data lake problem, not an application problem.

The operating model gap

The most common stall pattern we see: a bank builds technically compliant APIs, passes the regulator audit, and then watches usage stay near zero for 18 months. Why? Because the customer-facing experience of granting consent is buried six clicks deep in the mobile app, and the partner-onboarding process is run by a legal team that takes 90 days to review each fintech.

Open banking only delivers business value when the bank treats partner enablement as a product, not a compliance project. That means dedicated developer experience, sandbox access in under an hour, a partner success team, and SLAs that fintechs can actually rely on. None of this is in the regulation. All of it determines whether you are a hub or a backwater in your market’s ecosystem.

A 90-day pragmatic plan

Days 0-30: API surface audit, identity layer review, consent architecture design. Output: technical gap list with sizing.

Days 30-60: build the certified API gateway pilot (one product area), implement consent management, set up the auditable event log. Output: working sandbox, ready for partner onboarding.

Days 60-90: onboard 2-3 friendly fintechs, run end-to-end consent flows, validate against regulator spec. Output: regulator-ready submission plus a partner onboarding playbook.

Need a candid open-banking readiness assessment?

Our financial services architects have shipped open finance programs at LATAM banks since the first Brazilian phases. We will tell you where you actually are.

Book a readiness review →

OT/IT segmentation for manufacturers without breaking the plant

Insight · Manufacturing × OT Cybersecurity

OT/IT segmentation for manufacturers without breaking the plant floor.

By Inithex Practice · 8 min read · May 2026

Every CISO and CIO of a manufacturer we meet wants OT/IT segmentation. Every operations director who has lived through a botched segmentation project becomes a permanent veto. Both are right. The way to reconcile is a sequence — not a project — that respects both.

Why segmentation became urgent

Ransomware targeting plant operations grew significantly over the past 24 months. The economics work for attackers: a halted production line costs millions per day; ransom demands are calibrated against that. Industrial control protocols like Modbus, OPC-UA and PROFINET were never designed with authentication in mind. Once a corporate user clicks a phishing link and an attacker pivots from IT to OT, lateral movement to a PLC is often trivial.

Insurance carriers now require evidence of OT/IT segmentation. Customers — especially in regulated verticals like food, pharma and aerospace — increasingly include it in supplier audits. The cost of not having it is rising faster than the cost of doing it well.

The sequence we use

Step 1: OT asset discovery before anything else. Most plants have 30-50% more connected devices than the asset register shows. Run passive discovery (no active scanning — that itself can crash older PLCs) for 4-6 weeks to catalog everything talking on the network.

Step 2: Map real-world traffic flows. Which engineering workstation talks to which PLC? Which MES needs to reach which historian? Document the legitimate flows before designing the segmentation policy. We have seen segmentation projects that broke the production reporting because nobody noticed the historian was pulling data from the corporate ERP every 15 minutes.

Step 3: Design the zone architecture per the Purdue model (or your variant of it), with explicit DMZs between corporate IT and OT. The boundary devices — typically next-gen firewalls or unidirectional gateways for the most critical segments — become the enforcement points.

Step 4: Deploy in monitor mode first. For 4-8 weeks, the segmentation policy is in place but allows everything while logging violations. This surfaces the flows the discovery phase missed without halting production.

The mistakes we keep seeing

Mistake 1: starting with the firewall purchase. Vendors love a hardware-first approach because they sell hardware. The right sequence is discovery → flow mapping → architecture → enforcement, in that order. The firewall is the last decision, not the first.

Mistake 2: skipping monitor mode. Going from “no enforcement” to “block by default” is what kills production. Monitor mode is unsexy but irreplaceable.

Mistake 3: doing it without OT engineers in the room. Network engineers and SOC analysts cannot do this alone. The plant’s automation engineers know things about how their equipment actually behaves that no diagram captures.

What good looks like

A well-segmented plant has documented zones, enforced boundaries, monitored east-west traffic and a SOC playbook for OT-specific anomalies (e.g., an engineering workstation suddenly issuing PLC writes outside of its baseline). Mean time to detect an OT intrusion drops from never-detected to under 24 hours, often faster.

The production team gets faster troubleshooting because the network is now legible. The CISO gets the evidence the insurance carrier requires. Neither team has to fight the other. That is the goal.

Considering an OT/IT segmentation project?

Our manufacturing + Inithex security team has done this in food, mining and auto-parts plants across LATAM. We can sequence it without breaking your line.

Talk to our OT security team →

From 4 days to 10 minutes: the back-office truth

Insight · Financial Services

From 4 days to 10 minutes: what the back office really has to change.

By Inithex Practice · 6 min read · May 2026

We helped a regional bank cut digital account opening from 4.2 days to 10 minutes. The interesting part of that project was not the customer-facing form. It was the 38 back-office handoffs we removed to make the form’s promise actually true.

The form is the easy 20%

Customer-facing forms have become a solved problem. Modern frameworks render them beautifully, validate them client-side, and submit them painlessly. If the journey takes 4 days, the form is not the bottleneck. The bottleneck is what happens after Submit.

In the bank we worked with, Submit triggered: a manual KYC review queue, an AML screening that ran twice a day in batch, a sanctions-list check against an Excel-maintained file, a courier route between two branches for paper-signed forms, and a back-office reconciliation that ran when the accounting team got to it. Each step was a person plus a delay.

Mapping is not architecting

The org chart said the onboarding process had 6 steps. The actual journey had 38. We discovered the 38 by shadowing the back-office team for two weeks, not by interviewing managers. This delta — what people say happens vs. what actually happens — is the single largest gap in every digital transformation project we have run.

Once the real map exists, the target architecture writes itself. We collapsed the 38 handoffs into 4 automated checkpoints: identity verification, KYC + AML in a single orchestrated screen, e-signature, and funding. Every checkpoint is logged, recoverable and auditable.

What had to change in the back office

Real-time AML. The batch-twice-a-day model had to go. We integrated a real-time AML provider via MuleSoft. Capacity dimensioning, vendor SLA negotiation and exception handling were 6 weeks of work.

Electronic signature. Init.Sign replaced the courier-and-scanner workflow with legally binding e-signature under Ley 19.799. Legal and compliance approval took longer than the implementation.

Core banking integration. The core system’s account-creation API was synchronous, slow and brittle. We redesigned the integration as async with idempotency keys and a reconciliation job. This took the most engineering time.

Operating model. The back-office team’s job changed. Instead of processing onboardings, they now handle exceptions — typically 4-6% of submissions that fail KYC or AML and need a human. The team shrank, the work got more interesting, and the queue stayed empty.

What is non-negotiable

Two things have to be true for a project like this to land. First, executive cover for changing the back-office operating model. If the back-office leader is not in the room from week one, the form will ship and nothing else will. Second, security and compliance integrated into the design from day one, not as a gate at the end. Every checkpoint of the new flow has SOC monitoring and audit logs from the first deploy.

The bank we worked with has held zero material compliance findings since go-live, processes 10x the volume per back-office FTE, and saw under-35 acquisition jump 34%. The form is great. The form is also not the reason.

Modernizing your onboarding journey?

30 minutes with one of our financial services architects. We will share the playbook we used and tell you the realistic timeline for your context.

Talk to our FSC team →