Practice
Secured to the plan.
Oracle Cloud security is not a list of settings. It is one plan: an identity model, a tenancy architecture, an integration standard, a monitoring design and a set of guardrails that agree with each other. Our practice is built around producing that plan, proving it, and leaving it with your team in a form they can build from and audit against.
The five pillars
Five bastions around one estate.
The plan is drawn the way a fortification was drawn: every face covered by another. Each pillar is a service line; the estate in the middle is yours.
Identity & Access
Identity domains, SSO and federation, MFA, group-based access, SoD-aligned administrator groups, breakglass.
Fusion ERP
Role design, segregation of duties, sensitive access, automated controls, the security review of extensions.
OCI
Compartments, network, Cloud Guard, security zones, vault and key management, on the CIS benchmark.
Integrations
OIC, VBCS and API inventory; OAuth as the standard; confidential clients; exception sign-off for anything else.
AI Guardrails
Governance for AI Agent Studio and external model calls: identity, data controls, usage policy, monitoring.
The seven phases
In order, every time.
The phases say what gets delivered and in what sequence. Each one writes a section of the build document, and each one leaves an artifact you keep.
- Phase 0
Intake and documentation review
We read your existing documentation from the outside. We do not assess your infrastructure-as-code as if it were the tenancy: code states intent, and drift between intent and reality is where findings live. We assess what is running.
- Phase 1
Current-state capture
A diagram of the tenancy as it is: compartment structure, networking, identity domains, integration topology. It becomes the shared picture for every later conversation and the anchor diagram of the build document. We seed it from your intended design and mark every area to verify; verification turns drawing into correction.
- Phase 2
Baseline and posture
The CIS OCI Foundations Benchmark script is run against the tenancy and the report kept as the "before". Cloud Guard is enabled and its findings are worked to resolution. After remediation the benchmark runs again. The before-and-after pair is the proof of value.
- Phase 3
Identity and access
Fusion and OCI IAM configuration is reviewed and designed together: SSO on the default identity domain with SAML for user authentication, a breakglass account on the published Oracle pattern, IAM policies brought to the CIS standard, SoD-based administrator groups, group-membership-based access, least privilege throughout.
- Phase 4
Integration and extension security
Every PaaS integration is inventoried: Oracle Integration Cloud, Visual Builder, functions and APIs. OAuth is enforced as the standard; Basic authentication survives only with a documented review and exception sign-off. Fusion integrations run on confidential OAuth clients, one client per connection.
- Phase 5
Monitoring, logging and SIEM
Logs leave the tenancy through the Kafka-compatible streaming endpoint and Connector Hub into your SIEM, whichever consumer you run. Alarms and notifications are set for critical events, such as an identity-domain administrator role assigned directly to a user.
- Phase 6
Supplier Portal and external access
External users are set up on the current Oracle pattern: employees federate through the corporate identity provider, suppliers sign in directly with native MFA on OCI IAM, and no separate external identity domain is created. The domain that is never built is a licence and a running cost you never carry.
The deliverable
The build document.
One canonical deliverable per engagement. Its sections mirror the phases, and it is written so your own team can build from it and an auditor can check against it. Working artifacts are shared early and versioned; nothing is finished until it has survived contact with your environment and landed in the document.
- Current-state tenancy diagram
- CIS benchmark reports, before and after
- Cloud Guard posture and resolutions
- Identity, SSO and breakglass design
- IAM policy set to the standard
- Integration inventory and authentication standard
- SIEM and logging architecture
- Alarm and notification baseline
- Supplier Portal pattern
- Numbered findings register, F-01 onward
Operating rules
How the work moves.
The phases are the product. So is the way they are delivered.
Only what is defensible live
Every claim is verified against documentation before it is sent, or turned into a named test case. "We will confirm this in testing" is diligence, not uncertainty.
Questions answered with work product
A question on a thread becomes a matrix, a runbook or a one-pager and arrives as an attachment. The artifact inventory grows; the reply-all noise does not.
Your administrators run the tooling
Read-only scans run in your tenancy, by your people, from the published source. We never ask for elevated access to run a benchmark. A practice that recommends least privilege should not want it.
Findings register from week one
Findings are numbered from the first friction, before any scan completes. Every pain point your team already has is a candidate finding and a line in the build document.
Decisions get sessions, not email chains
A recommendation circulates, becomes a short deck, and is decided in a working session with owners assigned to each validation item. Sensitive asks get their own conversation.
Weekly status, Monday morning
What was completed, what is targeted next, itemised by stream so effort is legible. One meaningful delivery per day, sequenced, beats a Friday dump.
Start with an architecture review.
Phases 0 to 2 as a fixed-scope engagement: the diagram, the baseline, the findings register and a roadmap for the rest.