Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Apple > Operating Systems

  • Print
  • + Share This
This chapter is from the book

Creating a Cloned System Image

Creation of a cloned system image suitable for deployment involves just a few main steps:

  1. On a model system, install and update all necessary software, configure system settings, and perform any additional customizations.
  2. Purge the model system of files not suited for deployment.
  3. Copy the model system to a read-only (optionally compressed) disk image.
  4. Prepare the system image for deployment.

Required Equipment

To create a cloned system image, you need either two Mac computers or one Mac with two bootable volumes that have Mac OS X v10.5 installed. If you have two Mac computers, one will be used to build the model system, and the second will be used to create the cloned system image. If you are using one Mac with two separate bootable volumes, one volume will be used to build the model system, and the other volume will be used to create the cloned system image.

If you are using two separate Macs, you will also need a FireWire cable to connect the two so you can clone the model system to the creation system.

In either case, make sure that both the model and creation volumes have enough room to build your cloned system image. The model volume needs enough room to install the system and any additional items you intend to deploy, and the creation volume needs roughly twice the available space used on the model volume. Thus, if your model volume uses 10 GB of storage space, your creation volume needs 20 GB of available space.

Customizing the Model System

Your first step is to create and customize your ideal model system, installing and updating all necessary system software, application software, and support software and configuring as many settings and preferences as possible.

Assuming you meet the prerequisite level of knowledge suggested by this guide, equivalent to the requirements for Apple Certified Technical Coordinator certification, you should already have a good idea of how to configure your model system. In this section, you will learn to perform advanced customizations to further optimize your system image for deployment.

Each custom configuration demonstrated in this section can be used individually, but when combined, they allow you to present the user with a system that is tightly integrated with your organization and its policies.

Restarting the Setup Assistant

The Setup Assistant is the first interface most Mac OS X users see when they start a new Mac for the first time. The Setup Assistant guides the user through the process of configuring initial settings, including the creation of an administrative user account. However, after this initial setup is complete, the Setup Assistant no longer appears at startup. You can force the Startup Assistant to run at the next system startup to give users some control over their own computers, including the ability to create their own user accounts.

If you want to make the Startup Assistant run at the next system startup, simply remove the /var/db/.AppleSetupDone file. This file is protected by root access, so the quickest method to remove this file is to enter sudo rm /var/db/.AppleSetupDone at the command line. When a user restarts the computer, the Setup Assistant will launch, allowing the user to make several configuration changes. This potentially includes changes that are not ideal for your deployment, including the following:

  • The user will be allowed to set the default keyboard and language, enter registration information, their Apple ID, and .Mac information, and reset the time zone.
  • If networking is already set up, the user will not be allowed to configure any network settings at this point.
  • The user will be able to create an additional administrative user account.
  • The Setup Assistant will enable automatic login for the newly created user.
  • The Setup Assistant will change the computer’s name using the following convention: new user’s name followed by the computer model.

Unfortunately, you cannot limit what the Setup Assistant allows the user to configure. If you still want to use the Setup Assistant but you need to limit the changes, you can implement a script to automatically reset some of these items after the Setup Assistant finishes. Techniques for implementing such a script is covered in Chapter 6, “Postimaging Deployment Considerations.” If you change your mind about restarting the Setup Assistant, you can easily replace the appropriate file by entering sudo touch /var/db/.AppleSetupDone at the command line.

Customizing the Setup Assistant

To customize your users’ new Mac experience, you can change the QuickTime video and MP3 audio files played at the introduction of the Setup Assistant. You can use any content-creation tool you like to create custom organization-specific replacements for these files. For instance, you could create a movie that reminds the user of your organization’s usage policies, or you could create replacements that essentially play nothing. When creating your custom introduction media, keep in mind that the video and audio files start playing simultaneously, but the video ends before the audio file to allow the user to continue the setup process accompanied by background music.

The files you must replace are located inside the Setup Assistant package, in the /System/Library/CoreServices/Setup folder. In this folder you will need to replace the and intro-sound.mp3 files. These files are protected by root access, and you should back them up just in case you need to return the Setup Assistant to its original state.

In the following example, Michelle uses the command line to back up the original audio and video files, and then replace them with two custom files that she has created on her desktop. Michelle first navigates to the appropriate folder inside the Setup Assistant package. Notice that she uses the sudo command to bypass the file system permissions.

MyMac:~ michelle$ cd "/System/Library/CoreServices/Setup
MyMac:Resources michelle$ sudo mv
MyMac:Resources michelle$ sudo mv intro-sound.mp3 intro-sound.mp3.old
MyMac:Resources michelle$ sudo cp /Users/michelle/Desktop/
MyMac:Resources michelle$ sudo cp /Users/michelle/Desktop/customsong.mp3 intro-sound.mp3

Customizing the Login Window Message

You can also customize the login window to meet your organization’s deployment needs; for instance, display information such as usage policies. Ideally, you should configure custom login window settings using MCX settings hosted on a directory server. However, if you don’t have a directory service capable of hosting MCX settings, you can enable these settings on your model system and make them part of your system image deployment.

The login window is managed by the loginwindow process, which references settings located in the /Library/Preferences/ preference file. You could edit this file using the Property List Editor application included with the Xcode Tools suite, but it’s much quicker to use the defaults write command to add the necessary customizations to this file. Because this file is protected by root permissions, you would use the sudo command to bypass those restrictions.

Using the defaults command, you must add a new property key, LoginwindowText, to the loginwindow preference file. The value for this new key will be the string of text you want shown at the login window inside quotation marks. For example, to customize the login window text with a usage policy notice, you would enter the following at the command line:

sudo defaults write /Library/Preferences/ LoginwindowText "By
logging in to this computer you are agreeing to the usage policies found in Pretendco
document UP-1052. Thank you, and have a nice day."

To test your custom configuration, log out of your current session and observe the login window.

Customizing the User Template

Whenever a local or mobile user account is created, the system also creates a local home folder for that user. The contents of these created home folders are based on the system’s user template. You can customize this user template to prepopulate new users’ home folders with any items, including preference settings.

For example, you can customize the user template to set a default background for every user, perhaps presenting usage policies or help information for novice users. However, the desktop background is saved as a per-user setting, and the user can change it at any time from the Desktop & Screen Saver preference or iPhoto.

Ideally, to set and lock specific user settings, you should use MCX settings hosted on a directory server. However, if you don’t have a directory service capable of hosting MCX settings, you can place user-specific preference files containing the settings in the user template on your model system and make them part of your system image deployment.

To set the desktop background using the user template:

  1. Log in to your model computer with an administrative account.
  2. Place the image file you want to set as the desktop background in a location that all users will be able to access, such as the /Library/Desktop Pictures folder.
  3. Open the Desktop & Screen Saver preference and set the desktop background for the administrative account to the desired image file. You will have to drag the image file from the desktop into the image well area at the upper-left corner of the preference pane.
  4. Set any additional desktop background features, and then close the Desktop & Screen Saver preference.

    This creates a properly formatted desktop property list preference file in the administrator’s home folder.

  5. Copy the file from the administrative account’s ~/Library/Preferences folder to the appropriate folder in the user template: /System/Library/User Template/English.lproj/Library/Preferences/.

    This folder is protected by root access, so you will have to use the command line to copy this file into the appropriate location. In the following example, Michelle uses her administrative account to copy the desktop preference file into the user template.

    MyMac:~ michelle$ sudo cp "/Users/michelle/Library/Preferences/"
    "/System/Library/User Template/English.lproj/Library/Preferences/"
  6. Protect the desktop image file and desktop preference file from modification. This requires changing the files’ ownership and permissions to be writable only by root but still readable by everyone else, and then setting the lock flag.

    Again, because these items will have root permissions, the quickest method is to use the command line. In the following example, Michelle changes the ownership, permissions, and lock flag for the pretendco.jpg image file and the desktop preference file inside the user template.

    MyMac:~ michelle$ sudo chown root:wheel "/Library/Desktop Pictures
    /pretendco.jpg" "/System/Library/User Template/English.lproj
    MyMac:~ michelle$ sudo chmod 644 "/Library/Desktop Pictures
    /pretendco.jpg" "/System/Library/User Template/English.lproj
    MyMac:~ michelle$ sudo chflags uchg "/Library/Desktop Pictures
    /pretendco.jpg" "/System/Library/User Template/English.lproj

Normally when the user template items are copied to create the new user’s home folder, the ownership and permissions are set so the items belong to the user. However, because you set the lock flag, the copied desktop preference file will retain the original ownership and permissions you have set here. Thus, users will not be allowed to change the desktop background setting even if they have access to the Desktop & Screen Saver preference. The system preference will still remain active and allow the user to interact with the settings, but the desktop background will never change.

Creating a Hidden Administrator

Perhaps the cleverest advanced customization you can make to your model image is hiding the local administrative user’s account from the primary users of the computer. If the administrator’s account isn’t hidden, users can view the local user list at the login window, the fast user switching menu, and the Accounts preference; they can also see other users’ home folders in the /Users folder from the Finder and command line and when connecting remotely to a Mac that has file-sharing services enabled.

The technique covered here will hide all these clues from every user and will even hide the account from other administrative users. Although an administrative user who knows exactly what to look for can easily uncover and delete your hidden administrator, the vast majority of users will have no idea that the account is even there.

To create a local hidden administrative account:

  1. Log in to your model computer with an administrative account.
  2. Open the Accounts system preference, click the Login Options button, and set “Display login window as” to “Name and password.” Disable automatic login if you haven’t done so already.
  3. While still in the Accounts system preference, create a new administrative user account. Make sure to choose an appropriate short name as that will be this user’s primary login name. Also, do not activate FileVault for this user. Click Create Account when you are done.
  4. In the accounts list, right-click or Control-click the entry for your new administrative account and choose Advanced Options from the shortcut menu.
  5. In the Advanced Options dialog, change the user ID to 499 and the home directory location to any path that an average user would never navigate to. For instance, you could choose any folder normally hidden in the Finder. Then click OK.

    A good location to store the hidden administrator’s home folder is inside the /var folder. You can further “hide” the home folder by giving the home folder a name that begins with a period. For example, if your hidden administrator’s short name is hadmin, a good hidden home folder path would be /var/.hadmin.

  6. Move and rename the hidden administrator’s home folder and set the appropriate ownership.

    Step 5 changed the hidden administrator’s user record, but in doing so you effectively removed access to this account’s original home folder. You must move the original home folder to the new path you chose in step 5 and correct the ownership for the home folder items.

    Because you’re modifying another user’s home folder, the fastest method to restore access is to use the command line. In the following example, Michelle will move and rename the hidden administrator’s home folder, and then set the appropriate ownership.

    MyMac:~ michelle$ sudo mv /Users/hadmin /var/.hadmin
    MyMac:~ michelle$ sudo chown -R hadmin /var/.hadmin
  7. Remove the Public and Sites folders from the hidden administrator’s home folder.

    Even though we have moved the hidden administrator’s home folder, it may still show up when various network sharing services are enabled. This is easily remedied by removing the Public and Sites folders from this home folder.

    Again, because you’re modifying another user’s home folder, the fastest method is to use the command line. In the following example, Michelle will remove the shared folders in the hidden administrator’s home folder.

    MyMac:~ michelle$ sudo rm -R /var/.hadmin/Public /var/.hadmin/Sites
  8. Modify the loginwindow settings so it does not show the hidden administrator account or any account with user IDs below 500. This will also prevent the Accounts preference and the fast user switching menu from showing accounts with user IDs below 500.

    The quickest method to set these custom settings is to use the defaults command. In the following example, Michelle will modify the loginwindow preferences to hide accounts with user IDs below 500, and then hide the hadmin account.

    MyMac:~ michelle$ sudo defaults write /Library/Preferences/
    Hide500Users -bool TRUE
    MyMac:~ michelle$ sudo defaults write /Library/Preferences/
    HiddenUsersList -array hadmin
  9. Test your work by logging out of your current account and then logging in as the hidden administrator.
  10. If everything is working properly, delete your initial administrator account because it’s not hidden.

    Aside from having an interesting location for the home folder, your hidden administrator account is identical in function to any other administrative account.

Purging the Model System

After you have completed all your model system customizations, you need to purge the model system volume of any items that should not be deployed to multiple computers, such as computer- and user-specific preferences and cache files that are not appropriate for other systems.

Once you have cleaned up the model system, be sure not to reboot it, otherwise many of the files you have purged will be re-created. If you must reboot the model system to make a correction, you will have to clean the system again. In fact, any time in the future when you need to update the cloned system image, you will have to reclean the model system volume before you can create a new cloned system image.

Working from the Creation System

It’s easiest to properly clean your model system volume from your creation system.

  1. Whether you’re using two separate Macs or two bootable volumes, shut down the model system.
  2. Now start using the creation system. You will need administrative access on the creation system.
  3. Mount the model system volume on the creation system.
    • If you’re using two separate Macs, restart the Mac with the model system volume in target mode by clicking the Target Disk Mode button in the Startup Disk system preference. Using a FireWire cable, plug the Mac with the model system into the booted Mac that will act as the creation system.
    • If you’re using a single Mac, use the Startup Disk system preference to set the creation system volume as the startup volume and restart the Mac.
  4. With the model system volume mounted on your creation system, rename the model system volume in the Finder. When you create a deployable system image, the name of the system volume will persist through the entire deployment to each system, so choose a name wisely.

    You could stick with the default Macintosh HD name, but to prevent accidentally targeting the wrong volume, and to further designate this as a custom system, you should change the model system volume name to something organization specific.

Removing User-Specific Files

Remove from your model system volume any user-specific files that are not necessary or are tied to computer-specific settings. In most cases the only local account left on your model system volume at this point is an administrator account. If you do have multiple local user accounts still on your model system volume, you will need to clean out each individual user’s home folder.

The following example presents a list of the user-specific files that should be removed from the model system volume. This example assumes the model system volume is mounted to a creation system, is named PretendcoHD, and that the only local user account on the model system is Michelle. The only command needed is sudo rm -rf, so you could enter all these items in a single command, but they are on separate lines here for easier reading.

sudo rm /Volumes/PretendcoHD/Users/michelle/Send Registration
sudo rm -rf /Volumes/PretendcoHD/Users/michelle/Desktop/*
sudo rm -rf /Volumes/PretendcoHD/Users/michelle/Downloads/*
sudo rm -rf /Volumes/PretendcoHD/Users/michelle/Library/Caches/*

Removing Computer-Specific Files

You should also remove from your model system volume any computer-specific files that are not necessary. The following example presents a list of the computer-specific files that should be removed from the model system. This example assumes the model system volume is mounted to a creation system and is named PretendcoHD. Again, the only command needed is sudo rm -rf, so you could put all these items in a single command, but they are on separate lines here for easier reading.

sudo rm -rf /Volumes/PretendcoHD/Documentation/old_*
sudo rm -rf /Volumes/PretendcoHD/Library/Caches/*
sudo rm -rf /Volumes/PretendcoHD/System/Library/Caches/*
sudo rm -rf /Volumes/PretendcoHD/Users/Shared/*
sudo rm -rf /Volumes/PretendcoHD/var/db/volinfo.database
sudo rm -rf /Volumes/PretendcoHD/var/vm/swap*
sudo rm -rf /Volumes/PretendcoHD/var/vm/sleepimage

There are several folders of computer-specific preferences that may also cause you problems when deploying to different types of hardware or computers destined for users with different levels of managed client settings. Whether you have to remove files from these folders depends on your specific deployment scenario. In some cases you may have to modify these items after system deployment, as covered in Chapter 6, “Postimaging Deployment Considerations.” However, if you experience configuration problems when testing your deployment, these folders will contain your primary suspects:

  • ~/Library/ByHost/—This folder is in every user’s home folder and holds preference files that are both user specific and computer specific. By default, none of these preferences will work on other systems.

  • /Library/Preferences/SystemConfiguration—This folder contains fundamental system configuration information, such as power management and network settings. Many of these settings don’t translate to systems with different hardware configurations.

  • /Library/Preferences/DirectoryService—This folder contains all the Directory Service settings. In general, if you do any sort of authenticated binding, including Active Directory binding, these items do not work when deployed to multiple systems.

  • /Library/Managed Preferences—This folder contains the cache files used by the directory service MCX managed client system. These items should be cleared if you have defined computer-specific management settings from a directory server.

Cloning the Model to Create a System Image

Now it’s time to create a disk image of the model system volume. As you learned in Chapter 2, “Deploying Individual Items and Containers,” it’s fairly easy to create a disk image using the contents of a folder or volume. You can create disk images in the graphical interface using the Disk Image application and at the command line using the hdiutil command.

Here are a few tips to keep in mind when creating a cloned system disk image:

  • Make sure to specify just the model system image volume, not the physical drive, as the source for the cloned system image.
  • The cloned system image format must be read-only (optionally compressed) and not encrypted.
  • Always make sure to have roughly twice the amount of free space available on the creation volume as the amount of used space on the model system volume.
  • Using separate physical drives for the model system volume and the destination for the cloned system image will greatly reduce the disk image creation process.
  • If you are unable to create the cloned system image because the system is reporting “Resource Busy” errors, unmount but do not eject the model system volume, and then create the cloned system image. Both Disk Utility and the hidutil command will still be able to create a cloned system image from the unmounted model system volume.

Preparing the Cloned System Image for Deployment

There is one last step to prepare your cloned system image for deployment. The cloned system image must be scanned in preparation for the Apple Software Restore (ASR) process. As you will learn in greater detail in the “Deploying System Images” section later in this chapter, the ASR process is used to restore the system image contents to a storage volume for deployment. The image scanning process can be performed by the Disk Utility application or the asr command.

The image scan process calculates additional data checksums for the cloned system image and stores this information in the disk image file. This checksum data is later used to verify the system restoration process. The image scan process will also reorder the cloned system disk image file if it is not properly ordered for the network ASR process. If the disk image file needs to be reordered, the system will have to rewrite the file to the same volume. This reordering process is why you need roughly twice the free space on the creation system to prepare the cloned system image for deployment.

To scan your cloned system image from the Disk Utility application:

  1. Open the Disk Utility application and choose Images > “Scan Image for Restore.”
  2. In the Open dialog that appears, select your cloned system image.
  3. Authenticate as an administrative user to initiate the scan process.

    Depending on the size of your system image and the speed of your hardware, it can take anywhere from a few minutes to a few hours to complete the image scan process. During this time Disk Utility will show a progress bar dialog. When the process is complete, this dialog will let you know whether the image scan process was successful.

Scanning your cloned system image from the asr command is nearly as easy. The syntax is sudo asr imagescan -source followed by the path to the cloned system image. In the following example, Michelle scans the cloned system image she previously created, ClonedSystem.dmg on the external Storage volume. The asr command also displays image scan progress and success messages.

MyMac:~ michelle$ sudo asr imagescan -source /Volumes/Storage/ClonedSystem.dmg
Block checksum: ....10....20....30....40....50....60....70....80....90....100
asr: successfully scanned image "/Volumes/Storage/ClonedSystem.dmg"

Updating a Cloned System Image

One of the primary disadvantages of a cloned system image is that updates and changes are not easily made. Once a deployable system image is created, the image file itself can never be changed. Essentially, you have to replace your outdated cloned system image with a new cloned system image.

This process of having to build new cloned system images with every change is especially frustrating when you are testing and trying to work the kinks out of a new system deployment. Even the smallest change requires that you completely rebuild the entire system image.

There are three methods that you can use to update an existing cloned system image and still use your previous work as a starting point:

  • Retain the original model system volume and apply your updates to the model system. Once the model system is updated, create a new cloned system image as outlined previously in this section.
  • Restore the cloned system to a bootable volume as outlined in the “Deploying System Images” section later in this chapter. Treat this restored volume as the new model system and apply your updates. Once your updates are complete, create a new cloned system image.
  • Convert the cloned system image to a read/write disk image as outlined in Chapter 2, “Deploying Individual Items and Containers.” Mount the new read/write disk image that contains your cloned system and apply the changes to the mounted volume. Once your updates are complete, convert the system disk image back to a read-only format and then rescan the image for deployment.
  • + Share This
  • 🔖 Save To Your Account

Peachpit Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Peachpit and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Peachpit products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive:

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020