ISO 27001 in the HRIS Layer: How Workday and SAP Map to Annex A
ISO 27001 Annex A controls feel abstract until you map them to specific HRIS configuration items. Once you do, the test procedure becomes obvious. Here is how A.9, A.12, and A.14 translate to Workday, SuccessFactors, and Oracle HCM.
A.9 — Access Control
Maps directly to Workday security groups, ISSGs, and the ISU model. In SuccessFactors it is Permission Roles, Permission Groups, and RBP rules. In Oracle it is data roles and the security console role hierarchy. Evidence: quarterly privileged access review attestations + 'View Members of Security Group' exports.
A.12 — Operations Security
Maps to integration monitoring, alert subscribers, and change management. Evidence: 'View Integration System' showing alert subscribers, 'Integration Audit' showing failure response, change tickets for every Preview promotion.
A.14 — System Acquisition, Development & Maintenance
Maps to Preview promotion controls and calculated field validation. Evidence: change records showing config tested in Preview before production; 'All Calculated Fields' filtered Has Errors = No.
Multi-platform coverage in one scan
Yoetz.ai tags every finding with the matching Annex A control number. Fixing one ISU misconfiguration in Workday simultaneously satisfies A.9.2.3 and the equivalent ISO mapping in SuccessFactors and Oracle.
Why ISO 27001 auditors struggle with HRIS scope
Most ISO 27001 lead auditors are generalists. They are comfortable auditing network segmentation, endpoint controls, and physical access, but the HRIS tenant is often treated as 'just another SaaS application' on the asset register — a single line item rather than a system with its own security group model, integration surface, and configuration history. That under-scoping is a problem for two reasons. First, the HRIS typically holds the most sensitive personal data in the organisation: national identifiers, bank details, disciplinary records, compensation history, and — in many tenants — health and disability data captured through leave-of-absence workflows. Second, the HRIS is usually the system with the widest population of privileged users, because every HR business partner, every people manager, and every finance analyst touching payroll integration has some form of elevated access.
The practical consequence is that when the ISO 27001 internal audit or the certification body's surveillance audit reaches the HRIS, the auditor asks for 'evidence of access control' and accepts a screenshot of a role list, without probing whether that role list reflects the actual assignment of security groups in production. A properly scoped ISO 27001 audit of the HRIS layer needs configuration-level evidence, not policy-level evidence. This is where the gap between what the ISMS documentation says and what the tenant actually enforces tends to open up.
A.5 — Organisational controls and the HRIS asset owner
Annex A.5.9 requires an inventory of information and other associated assets, and A.5.10 requires acceptable use of those assets to be defined. In practice this means the HRIS tenant needs a named asset owner — usually the HRIS director or a senior Workday/SuccessFactors platform lead — who is accountable for the security group model, not just the HR business owner who is accountable for the process. Auditors will ask: who signs off on a new security group before it goes to production? If the answer is 'whoever raised the change ticket,' that is a finding against A.5.9 and A.5.10 simultaneously, because there is no accountable owner reviewing the asset's access model.
A.8 — Asset management and configuration items
A.8.1 (user endpoint devices) rarely applies directly to HRIS, but A.8.9 (configuration management) does, and it is the control most commonly missed. Configuration management in a Workday or SuccessFactors context means: is there a record of what changed, when, why, and who approved it, for every security group, business process definition, and integration credential? Most tenants have change tickets for major projects but not for the day-to-day tweaks — adding a domain to a group, widening a business process condition rule, adding a field to an integration payload. A.8.9 expects all of these to be tracked. The evidence an auditor wants is a configuration change log correlated against the tenant's actual audit trail (Workday's 'View Security Group' change history, SuccessFactors' Admin Center audit log, or Oracle's Configuration Audit report) — not just the change tickets that happen to have been raised.
A.9 — Access control in depth (beyond the base mapping)
- A.9.2.1 (registration and de-registration): tie to termination-to-deprovisioning latency in the HRIS itself — the system that runs the termination business process should also be the trigger for account deactivation, and the SLA (ideally under 24 hours) needs to be measured, not assumed.
- A.9.2.3 (privileged access rights): every ISU (Integration System User) is a privileged account for ISO 27001 purposes. It needs an owner, a documented business justification, MFA or IP-restriction compensating control, and a periodic access review — the same standard applied to human admin accounts.
- A.9.2.5 (review of user access rights): this is the control most organisations claim to satisfy with an annual access recertification campaign, but ISO 27001 auditors increasingly want evidence that the review actually resulted in changes — revoked access, narrowed security groups — not just a spreadsheet of sign-offs.
- A.9.4.1 (information access restriction): maps to domain-level security policies. An auditor testing this control will ask to see a sample of custom security groups and verify each is scoped to the minimum domain set needed for the role, not copied wholesale from an existing broader group.
A.12 in depth: logging, monitoring, and capacity
A.12.4 (logging and monitoring) is frequently satisfied on paper by pointing to the vendor's SOC 1 or SOC 2 report, which covers the vendor's own infrastructure logging. It does not cover tenant-level logging — whether your organisation has configured alert subscribers on integrations, whether failed business process routings are surfaced to anyone, and whether anomalous access patterns (a service account suddenly querying a much larger dataset than usual) would be noticed. ISO 27001 auditors who understand SaaS tenancy will separate 'vendor infrastructure logging' from 'tenant configuration logging' and expect evidence for both. A.12.1.2 (change management) reinforces the A.8.9 point above: every configuration change needs a controlled process, and Preview-to-Production promotion needs to be demonstrably gated, not optional.
A.14 in depth: secure development and testing
A.14.2.8 (system security testing) is often assumed to be irrelevant to a configuration-only SaaS platform, on the logic that 'we don't write code.' But calculated fields, custom business process rules, and integration transformation logic are code in every meaningful sense — they take inputs, apply logic, and produce outputs that drive pay, benefits, and compliance decisions. A.14.2.8 expects that logic to be tested before it reaches production. The practical test procedure is to sample a set of calculated fields and business process condition rules, confirm each has a corresponding Preview-environment validation record, and check the 'Has Errors' status of every field currently live in production. Calculated fields flagged with errors that are nonetheless active in production are a direct A.14.2.8 nonconformity.
A.16 — Incident management in an HRIS context
A.16.1 requires a documented process for reporting and managing information security events. HRIS-specific incidents rarely look like classic security incidents — they look like 'payroll ran with the wrong tax jurisdiction for 200 employees' or 'a security group change three weeks ago accidentally exposed compensation data to 400 managers.' Few incident response runbooks are written with these scenarios in mind. An ISO 27001 auditor testing A.16 against the HRIS should expect to see at least one worked example — a tabletop exercise or an actual incident — showing detection, containment, and root-cause analysis specific to a tenant misconfiguration, not just a generic IT security incident template.
A.18 — Compliance review and the annual attestation problem
A.18.2.2 (compliance with security policies) and A.18.2.3 (technical compliance review) both call for periodic, independent verification that controls are actually operating — not just documented. The most common failure mode here is that the ISMS documentation was accurate at the time it was written, twelve or eighteen months ago, and nobody has re-verified it against the current state of the tenant since. Given how frequently Workday, SuccessFactors, and Oracle HCM tenants change — new security groups for reorganisations, new integrations for point solutions, new business processes for policy changes — a technical compliance review that only happens once a year at recertification time is, by definition, checking a stale picture for most of the certification cycle.
Mapping ISO 27001 findings to remediation ownership
A finding without a named remediation owner tends to stay open indefinitely, because 'the HRIS team' or 'security' as a generic owner diffuses accountability across everyone and therefore no one. The most effective ISO 27001 remediation trackers assign each finding to a single named individual, a target closure date, and a re-verification step distinct from the original fix — someone other than the person who made the change confirms it actually resolved the underlying control gap. This is a small procedural discipline, but it is the difference between a finding that closes once and stays closed, and a finding that closes on paper and reopens quietly at the next audit cycle because the fix was only partially applied or was reverted by a subsequent unrelated change.
Certification body variability and how to prepare for it
Not all ISO 27001 certification bodies apply the same depth of scrutiny to SaaS HRIS platforms, and this variability is worth understanding rather than treating as a fixed standard. Some certification bodies have auditors with genuine SaaS tenancy experience who will ask pointed, configuration-specific questions; others apply a more generic checklist approach regardless of the underlying system. Rather than calibrating your evidence programme to the specific auditor you expect this cycle, build the evidence base to the higher standard consistently — a rigorous internal audit programme that would satisfy the most demanding certification body auditor will always satisfy a less demanding one, but the reverse is not true, and auditor assignment can change between cycles without notice.
Integrating ISO 27001 evidence with other framework requirements
Organisations juggling ISO 27001 alongside SOC 2, SOX, or GDPR obligations often duplicate evidence-gathering effort across frameworks that are, in practice, asking overlapping questions of the same underlying tenant configuration. A security group's domain scope is relevant evidence for ISO 27001 A.9, SOX access controls, and GDPR data minimisation simultaneously. Building a single evidence repository tagged against multiple framework requirements — rather than separate evidence exercises run by separate teams on separate calendars — reduces both the total effort and the risk of the different framework owners reaching inconsistent conclusions about the same underlying configuration state.
Common surveillance audit findings in year two and three
- Security groups created during the certification year were reviewed carefully; groups created in year two or three of the certification cycle often receive noticeably less scrutiny and accumulate the same unconstrained-access patterns the original certification audit found and remediated.
- ISU credentials rotated ahead of the initial certification audit frequently drift out of rotation cadence by the second surveillance visit, once the initial audit pressure has passed.
- Configuration change logging that was tightened for the certification audit sometimes reverts to informal tracking once the immediate audit deadline is behind the team.
- New integrations added after certification are less consistently assessed against the original Annex A control mapping than the integrations that existed at certification time.
Building continuous evidence instead of point-in-time evidence
The most durable way to pass ISO 27001 surveillance and recertification audits on the HRIS in-scope boundary is to stop treating the audit as an annual event and start generating the evidence continuously. A quarterly automated scan that tags findings against the specific Annex A control number they violate turns the audit conversation from 'let us pull together evidence for you' into 'here is the evidence trail for the last four quarters, already mapped.' This also solves the A.18.2.3 technical compliance review requirement directly, because the scan is the technical compliance review, run on a cadence rather than once a year under audit pressure.
Budgeting for the ISMS documentation update cycle
Every configuration-level finding surfaced during an ISO 27001 audit eventually needs to be reflected back into the ISMS documentation itself — the risk register, the statement of applicability, and the control descriptions — or the documentation drifts further from reality with each cycle. Organisations that treat the HRIS-specific findings as purely a remediation exercise, without updating the underlying ISMS narrative to describe how the control actually operates today, end up rediscovering the same documentation gap at the next certification audit. Build a standing agenda item into your ISMS steering committee to review HRIS scan findings quarterly and update the relevant Annex A control descriptions and risk register entries in the same cycle, rather than leaving documentation updates to the annual management review alone.
The role of the HRIS platform team in ISMS governance
ISO 27001 governance structures are usually built around a central information security function, with the HRIS platform team treated as a downstream stakeholder that responds to requests rather than an active participant in ISMS governance. This works reasonably well for infrastructure-level controls, but it under-serves HRIS-specific controls because the information security function rarely has the platform depth to know what a well-scoped security group looks like, or what a properly gated Preview-to-Production promotion process should involve. The more effective model gives the HRIS platform lead a standing seat in the ISMS steering committee specifically for the duration that the HRIS is in scope, so that control descriptions and risk assessments reflect actual platform behaviour rather than a security team's best approximation of it.
Frequently asked questions
Does ISO 27001 certification require a separate audit of the HRIS platform?
Not a separate certification, but the HRIS must be included in the ISMS scope statement if it processes personal data or supports in-scope business processes, and it must be tested during internal audits and by the certification body during surveillance visits like any other in-scope asset.
Which Annex A controls do Workday and SAP SuccessFactors auditors focus on most?
In practice, A.9 (access control) and A.12 (operations security) receive the most attention because they map most directly to security groups, ISUs, and integration monitoring. A.14 and A.18 are tested less consistently, which is exactly where gaps tend to persist unnoticed.
Can a SOC 1 or SOC 2 report from Workday substitute for our own ISO 27001 evidence?
No. The vendor's SOC report covers the vendor's infrastructure and shared responsibilities; it does not cover how your organisation configured security groups, business processes, or integrations within your tenant. You still need tenant-level evidence for A.9, A.12, and A.14.
What happens if an ISO 27001 surveillance auditor finds an unremediated issue from the previous audit?
It typically becomes a more serious finding than if it were new, because it demonstrates the organisation's corrective action process did not function as documented. Repeat findings are one of the more common triggers for a certification body to escalate scrutiny or, in serious cases, threaten suspension of certification.
Does adding a new HRIS module (for example, a new Workday module) require re-scoping the ISMS?
Yes, in most cases. A new module often introduces new security groups, new integrations, and potentially new categories of personal data, all of which should trigger a re-assessment of whether the ISMS scope statement and risk assessment still accurately describe the environment.
Should the HRIS security group audit be performed by the same team that manages the tenant day to day?
Independence matters here. Whoever configures security groups should not be the sole party attesting to their correctness for audit purposes; a second, independent reviewer — internal audit, a separate security function, or an automated tool — should verify the configuration independently of the team that built it.
How often should we re-verify Annex A control evidence for the HRIS in-scope boundary?
At minimum quarterly, and after any significant release (Workday's biannual updates, SuccessFactors' quarterly releases) or major reorganisation that touches the security group model, since these are the events most likely to introduce new gaps between documented and actual control operation.
Continue reading
Find out what's broken in your tenant
Free first scan. Read-only access. Results in under 2 hours.
Start Your Free Scan