Greenfields GRC: Security Assurance When the System Does Not Exist Yet

There is something fundamentally different about undertaking governance, risk and compliance in a greenfields technology environment. Most traditional approaches to security assurance were built around the assumption that there is a system to assess: an architecture that has settled, controls that have been implemented, configurations that can be examined, evidence that can be collected and a reasonably stable environment against which an assessor can reach a conclusion. Greenfields programs invert that assumption. Security assurance begins while the system itself is still being designed, while architecture is changing, while identities and networks are being established, while applications are still being selected or developed, and often while the organisation is simultaneously trying to meet an immovable migration or operational deadline. The challenge for GRC is therefore not simply to assess compliance earlier; it is to provide meaningful assurance about a system whose security posture is continuously emerging.

This distinction matters because a greenfields program can very quickly confuse architectural intent with implemented security. A design may show Zero Trust, segmentation, privileged access management, conditional access, centralised logging and sophisticated threat detection, but a diagram does not make any of those controls effective. The Australian Signals Directorate's current cyber security principles explicitly place systems within a lifecycle in which they are planned, designed, developed, tested, deployed, maintained and ultimately decommissioned according to their security and resilience requirements. ASD's Secure by Design guidance similarly emphasises that security needs to begin at inception, design and architecture and then remain sustained throughout the lifecycle, rather than being applied as a compliance exercise near the end.  This is precisely where greenfields GRC needs to operate: not at the end of the build asking whether somebody remembered security, but alongside delivery continuously determining what is known, what is assumed, what has been implemented and what remains uncertain.

The most important discipline in doing this well is recognising that designed, implemented, evidenced and effective are not interchangeable security states. A control can be beautifully designed and never implemented. It can be implemented but incorrectly configured. It can be correctly configured but have no evidence available to demonstrate that fact. It can also be configured exactly as intended but prove ineffective when confronted by a realistic attack path. In a greenfields environment, these distinctions become particularly important because different parts of the system will occupy different stages simultaneously. One capability may have completed implementation and testing while another exists only as a high-level design, and a third may be operational but changing so rapidly that yesterday's evidence no longer represents today's configuration. A credible assurance position must be capable of representing all three without forcing them into an artificial binary of "compliant" or "non-compliant".

This is why I see greenfields GRC as fundamentally an exercise in progressive assurance. Early in the lifecycle, assurance necessarily concentrates on architecture, threat modelling, security requirements, control selection, system boundaries, trust relationships and design decisions. At this point, we can establish whether the proposed environment is capable of achieving the required security outcome, identify foreseeable risks and prevent expensive architectural mistakes before they become embedded. ASD's Secure by Design guidance makes exactly this point: considering security during inception, design and architecture can avoid the significant cost associated with later rework and can remove entire classes of vulnerability before development begins.  The value of GRC at this stage is therefore not measured by how many controls have been marked compliant, but by how effectively security risk is influencing the system that is being built.

As implementation progresses, however, the assurance question must change. We move from asking whether the proposed control is appropriate to asking whether it actually exists, whether it has been implemented as designed and whether there is evidence demonstrating that implementation. Eventually, we need to ask the harder question of whether the control is actually effective. That progression can be expressed simply as Design → Implementation → Evidence → Assessment → Effectiveness → Residual Risk, but there is an enormous amount of discipline contained within it. NIST's Risk Management Framework similarly treats control selection, implementation, assessment, authorisation and continuous monitoring as related but distinct lifecycle activities, while explicitly integrating security risk management into the system development lifecycle rather than positioning it as a final gate.

This approach also changes the relationship between GRC and delivery. In a greenfields program, there is often a tendency for anything with the word "security" attached to it to migrate toward the security assurance team. If a security document does not exist, GRC is asked to write it. If technical evidence does not exist, GRC is asked to find it. If a control has not been documented, GRC can find itself being asked to describe how it has been implemented. Eventually, the same team that is expected to independently determine whether a security control is effective becomes responsible for creating the evidence intended to prove that conclusion. This is not an effective assurance model, and it becomes particularly problematic in large transformation programs where a small GRC function can inadvertently become the documentation and evidence-production function for dozens of technical delivery teams.

Greenfields GRC therefore requires particularly clear control ownership. The team implementing identity needs to demonstrate how identity controls have been configured. The team implementing the cloud platform needs to provide the relevant platform configuration and architecture. The team implementing network segmentation needs to demonstrate that segmentation exists. The team operating security monitoring needs to demonstrate that the required telemetry is being received, retained and acted upon. GRC's role is then to determine whether that evidence demonstrates the required security outcome, identify where it does not and articulate the resulting risk. This is consistent with the broader risk-management principle of establishing responsibility and accountability for controls implemented within systems, including controls inherited from elsewhere in the organisation.  Independence is not an administrative nicety in this model; it is what gives the assurance conclusion its value.

The same principle applies to inherited controls, which become increasingly important as greenfields environments move toward shared cloud platforms and enterprise services. A new application should not need to independently recreate every identity, monitoring, network or platform control if those controls are genuinely provided by an underlying assured service. Equally, inheritance cannot simply become a convenient label for controls nobody has assessed. Greenfields GRC needs to understand exactly where the control is implemented, who owns it, what evidence establishes its effectiveness, what assumptions the consuming system makes about it and what happens if the inherited service changes. This creates a far more scalable assurance model because the organisation begins to assess reusable security capabilities rather than repeatedly assessing the same underlying technology through the lens of every new application.

Zero Trust provides a particularly useful example of why these distinctions matter. Modern cloud environments increasingly contain technologies capable of delivering sophisticated Zero Trust controls, but purchasing or deploying those technologies does not establish a Zero Trust environment. ASD's modern defensible architecture guidance describes Zero Trust through concepts including never trust, always verify, assume breach and verify explicitly, alongside layered architecture and Secure by Design practices.  Microsoft similarly describes the core Zero Trust principles as explicit verification, least-privilege access and assuming breach, with access decisions based on available signals and risk rather than implicit trust.  If an organisation has deployed the technologies capable of doing this but identity provisioning remains immature, conditional access is incomplete, privileges remain persistent or device trust is not yet enforced, then the honest assurance conclusion is not that Zero Trust has failed. It is that Zero Trust is the target architecture and has not yet been fully implemented.

That distinction is one of the most important things GRC can provide to executives. A greenfields environment should be allowed to be immature while it is being built. What it should not be allowed to do is become unintentionally represented as mature because the documentation describes the destination rather than the present state. There is nothing inherently wrong with saying that a control is designed but not yet implemented, or implemented but awaiting evidence, or evidenced but awaiting assessment. These are perfectly legitimate stages of system development. The problem arises when those distinctions disappear and planned controls begin silently contributing to a residual risk assessment as though they were already effective.

This also means that risk acceptance becomes an essential mechanism for enabling greenfields delivery rather than an indication that security has somehow failed. There will inevitably be stages where the program needs to continue while security controls remain incomplete. The correct response is not necessarily to stop all work until the final security architecture exists, but neither should the resulting exposure disappear into project scheduling. The uncertainty should be identified, the consequence understood, the treatment planned and the decision placed with the person who has the authority and accountability to accept that risk. This allows delivery to continue while preserving the integrity of the security assessment, and it provides executives with the information necessary to make genuinely risk-informed decisions, which is also a central purpose of lifecycle risk management approaches such as NIST's RMF.

Evidence itself becomes another interesting problem because, in a rapidly evolving environment, security evidence has a shelf life. If an assessment must be completed several weeks before migration, while technical teams continue changing the system during those weeks, the assessment necessarily describes the environment that existed when the evidence was collected. The closer a program gets to production, the more consequential that distinction becomes. A firewall configuration, privileged access model, Conditional Access policy or logging configuration captured a month earlier cannot automatically demonstrate the state of the environment on migration day. Greenfields assurance therefore needs configuration baselines, evidence dates, change records and delta assessments so that we understand not simply what was assessed, but whether the assessment still represents the system we are about to rely upon.

This is where continuous assurance stops being a fashionable phrase and becomes an operational necessity. NIST's RMF explicitly promotes continuous monitoring and near-real-time risk management as mechanisms for maintaining awareness of the security state of systems rather than repeatedly treating authorisation as a point-in-time exercise.  ASD's current cyber security principles similarly span governance, identification, protection, detection, response and recovery, reinforcing that security is a lifecycle activity rather than something completed when an accreditation package is signed.  For a cloud-based greenfields environment, where configurations and services may continue changing well after migration, this is a much more realistic model than assuming the environment somehow becomes static when it reaches production.

There is also an important practical consequence for migration decisions. Programs naturally focus enormous attention on the date people or workloads need to move, and that deadline can inadvertently become the point around which every assurance activity is compressed. Implementation, evidence production, assessment, remediation and executive risk decisions are then expected to happen almost simultaneously. They cannot. Evidence cannot meaningfully be assessed before it exists, remediation cannot occur before findings are understood, and an executive cannot make a properly informed residual risk decision before the uncertainty has been articulated. Greenfields GRC needs to make these dependencies visible early enough that the program can either sequence them properly or consciously accept the consequences of not doing so.

The migration date should therefore be viewed as a security transition point rather than the finish line. Some controls should be hard gates because operating without them would expose the environment to unacceptable risk. Others may legitimately continue maturing after migration under explicit risk acceptance and a defined treatment plan. Still others may only become meaningfully assessable once real users, data and operational processes exist. The important thing is that these categories are deliberate. A program should know what must be true before migration, what may remain transitional at migration and what evidence will subsequently be required to move from conditional operation toward full authorisation.

This is ultimately why I think good greenfields GRC can make technology programs faster rather than slower. Security requirements identified during architecture are cheaper to implement than controls discovered immediately before production. Evidence requirements defined before technical teams start building are easier to satisfy than evidence reconstructed months afterwards. Common controls identified early can be inherited rather than repeatedly reassessed. Risks surfaced while executives still have choices are easier to manage than risks discovered after migration has become unavoidable. ASD's Secure by Design approach is built around this same premise: security considered early and sustained throughout the lifecycle creates more resilient systems and avoids the cost of trying to retrofit security later.

The measure of successful greenfields GRC should therefore not be the volume of documentation produced or the number of controls coloured green. It should be whether the organisation understands the security state of the system at each point in its development, whether important risks are visible before they become irreversible, whether technical teams know what they need to implement and evidence, whether assessors retain sufficient independence to provide meaningful assurance, and whether executives understand the residual uncertainty when they make decisions. The security documentation remains important, but it is the record of that process rather than the purpose of it.

For me, that is the real opportunity presented by greenfields GRC. We are not trying to take a finished system and prove retrospectively that security was considered somewhere along the way; we have the opportunity to make risk, architecture, control implementation and assurance part of the way the environment is built in the first place. When that is done properly, the eventual System Security Plan, Statement of Applicability, risk assessment and authorisation package should contain very few surprises, because they are simply recording a security journey that has been visible and deliberate throughout the build. Greenfields GRC at its best is therefore not compliance before production; it is the discipline of progressively turning security intent into demonstrable security reality, while remaining completely transparent about the distance that still exists between the two.

Using the short-form vs long-form assessment model we established earlier, I would separate assessment production time from actual assurance/risk closure. A short-form assessment can substantially reduce GRC drafting effort, but it does not reduce the underlying security/supply-chain risk where evidence is absent.

For Shak's updated list, I would estimate it as follows.

Tool / capability	Assessment approach	Short-form effort	Long-form effort if required	Indicative risk if short-form only
Cognillo Broken Link Manager	Third-party/SCRM	4–6 hrs	2–3 days	Medium–High pending supplier/API/data evidence
LinkTek LinkFixer	Third-party/SCRM	4–6 hrs	2–3 days	Medium–High due potentially broad file/data access
PnP Search	Technical / OSS assessment	2–4 hrs	1–2 days	Medium if deployment restricted to controlled DevSecOps pipeline
PnP Search Extension	Bundle with PnP Search	1–2 hrs incremental	0.5–1 day	Medium subject to code/dependency validation
Microsoft Clarity	Privacy/data-flow assessment	2–4 hrs	1–2 days	Medium–High if behavioural telemetry leaves departmental boundary
Google Analytics / GA4	Third-party analytics/data	4–8 hrs	2–4 days	High until data flows, sovereignty/privacy and intranet content exposure are established
Azure App Insights	Existing platform capability	1–2 hrs	0.5–1 day	Low–Medium subject to configuration/data residency
SPFx Application Customizer	Technical/configuration	2–3 hrs	1–2 days	Medium if site-scoped and pipeline controls verified
Accelerator 365	Remove/reject as redundant	<1 hr	N/A	N/A if not deployed
Accessibility Assistant	Already approved	<1 hr	N/A	Low / inherited
Microsoft Forms	Already approved	<1 hr	N/A	Low / inherited, subject to approved configuration
Viva Connections	Out of current scope	<1 hr to record	1–2 days if reintroduced	N/A if excluded

What this means for the urgent request

If the program wants short-form assessments for everything remaining, I would estimate approximately 3–5 GRC person-days just to produce defensible initial assessments, assuming the information required is actually supplied.

That is materially different from saying:

“Cyber can approve these tools in 3–5 days.”

A short-form assessment should instead produce one of four outcomes: acceptable within existing controls; acceptable with conditions; further assessment/evidence required; or not supported in the proposed configuration.

The two genuinely new third-party products — Cognillo and LinkTek — should not receive unconditional approval simply because the program has requested an urgent short assessment. Their short-form assessments can identify the preliminary risk and minimum conditions, but the residual risk should remain Medium–High until supplier, access, data-flow and security evidence is obtained.

The analytics combination is potentially the highest concern. GA4 and Clarity on an internal departmental SharePoint environment can create a fundamentally different exposure from ordinary public-web analytics. Shak's observation about URL, metadata and behavioural information is important. A short-form assessment could therefore reasonably be completed in half to one day, but that does not make the risk low. I would retain High preliminary/unassessed risk for GA4 where the actual telemetry and offshore/external processing have not been demonstrated, reducing it only after evidence is assessed.

Calendar timeframe with the current GRC constraint

Even using short forms, I would put the planning estimate at:

Minimum: ~3 person-days if most items are immediately eliminated, inherited or bundled.

Realistic: 4–6 person-days for the remaining short-form assessments and decision records.

Elapsed: 5–10 business days, assuming reasonably complete information.

Where evidence is incomplete: short-form assessments can still be issued within that window, but explicitly as preliminary/conditional assessments with open risks and evidence requirements.

If the program requires full long-form SCRA/security assessments: approximately 10–18 person-days, potentially 3–6 weeks elapsed because supplier responses and technical evidence become the critical path.

That distinction is particularly important given the current resourcing position. The program can choose a shorter assurance product, but it cannot legitimately treat reduced documentation effort as evidence that the underlying risk has reduced.

I would capture the schedule assumption as:

Short-form assessment: 0.5–1 business day per substantive product, subject to available evidence. Short-form assessment provides preliminary risk disposition and conditions only. Where third-party access, data processing, sovereignty, privileged permissions or supply-chain risks cannot be adequately evidenced, residual risk remains elevated and a long-form assessment and/or additional technical validation will be required before unconditional production approval.

For the whole Shak list, 4–6 person-days / 5–10 business days elapsed is therefore the figure I would use in the GRC workload/Gantt rather than the earlier 8-day figure for fuller assessment. It also preserves the critical point that short-form is a prioritisation mechanism, not an assurance shortcut.